Announcement

Collapse
No announcement yet.

BUS1: A New Linux Kernel IPC Bus Being Made By Systemd Developers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • EduRam
    replied
    There is new information about it online!
    Synopsis

    bus1 is an inter-process communication bus system controlled by the kernel. It provides user-space with an API to create peers and send unicast and multicast messages between them. It does not enforce any layout on the transmitted data, but only provides the transport layer used for message interchange between peers.
    This set of man-pages gives a comprehensive overview of the kernel-level API, with all ioctl commands, associated structs and bit masks. However, most people will not use this API level directly, but rather let one of the high-level abstraction libraries help them integrate bus functionality into their applications.
    Last edited by EduRam; 23 March 2016, 08:00 AM.

    Leave a comment:


  • pgoetz
    replied
    Originally posted by nasyt View Post

    Runit represents deamons and even entire runlevels as directories. A deamon is a directory containing an executable file "run" that runs the service. A runlevel is a directory containing symbolic links to the deamon-directories. Starting and stopping of deamons happens through creating and deleting symbolic links
    Good heavens; you appear to know nothing whatsoever about systemd, which works roughly the same way. Services are started automatically when symbolically linked to a file in /etc/systemd/system. Having a service be stopped and started using symbolic links sounds like a cumbersome pain in the ass. When I'm testing a service I'll frequently stop and start it a dozen times while monitoring log file output: `systemctl restart service` allows me to do this painlessly. I don't want to have to remember to recreate a symbolic link that I might have deleted for testing so that the service will automatically restart on system boot.

    I'm 100% convinced (and have no evidence to the contrary) that the systemd haters are all people who haven't bothered to invest any time in learning how it works. If you're in tech it's your job to learn new tricks constantly. Just because you already know Sys V Init does not save you from having to learn something better when it comes along.

    Leave a comment:


  • pal666
    replied
    Originally posted by tigerroast View Post
    Linux stands for Linux Is Not UNIX. Because it's not UNIX.
    actually, the only relevant unix these days is linux

    Leave a comment:


  • EduRam
    replied
    Congrats Phoronix members ... I think this forum is currently the only one on Internet about bus1 !!!

    I think this project is an excellent opportunity to anyone to follow the source code development of a project from day one (while there is still a small code base). I'm checking daily it's github commits.

    But I have a question.
    What is the relation between "bus1/boot-efi" and "bus1/bus1" ?

    Thanks,

    Edu

    Leave a comment:


  • TeoLinuX
    replied
    Hilarious thing is that, if you write it down BUS ONE , well.... in italian slang "busone" is a derogative way of naming an homosexual...
    So this project sounds like what "fag" would for an english speaker.
    Just a funny curiosity, I'm in no way advocating any politically incorrect jokes/statements.

    Leave a comment:


  • nslay
    replied
    That's not true. A lot of software for Unix-like systems are relatively easy to port between other Unix-like systems. POSIX does a fairly good job at keeping source code for Unix-like systems interoperable. For everything else, generally sparse use of C preprocessors is sufficient.

    I more often struggle with convincing build systems to allow me to generate Makefiles for a platform that it thinks it doesn't support.

    Porting Unix-like software generally involves identifying pieces of code that query system information and adding some conditional C preprocessors and code snippet to query the system information for that flavor of Unix. This is relatively straightforward, although relatively cumbersome to debug (e.g. it may run, even if it's not working correctly!). Sometimes you also have to replace use of extensions to POSIX functionality (e.g. Linux extends pthreads in some places if I remember correctly).

    Of course, figuring out how to query information can sometimes be challenging due to lack of documentation. I ported wmwlmon to FreeBSD a long time ago and had to read ifconfig's source code to understand how to talk to the net80211 stack (wmwlmon is a WindowMaker dockapp originally written for OpenBSD). It probably took a couple hours to port, spent mostly learning how to do net80211 ioctl() queries.

    Although porting generally involves these small C preprocessor annotations and code snippets, large projects may have A LOT of those and it may be time consuming to identify and debug. But it's generally still doable.

    But it's not always this easy. For example, if you run into code that uses ALSA, you have to rewrite large chunks of the software since everyone else uses OSS for sound. This is the aspect I'm complaining about with BUS1. BUS1 could very well make it extremely challenging to port to other Unix-like systems, much like ALSA.

    Leave a comment:


  • unixfan2001
    replied
    nslay

    While I disagree with his definition of portability, the basic message is essentially right.
    Very few of the software found on *nix is actually portable. Even the Bourne shell wasn't portable. It's a complete myth that software is easily transferable between different *nix systems (see LibreSSL for another grand example of software that isn't portable without adding a shim on top).

    As for KDBUS and BUS1

    1. KDBUS is, at least nominally, quite different from DBUS1 (the current userspace implementation of DBUS). For one, it utilises Linux access control lists.
    2. While old code can simply hook into the supplied user-space proxy, software using the new KDBUS API probably won't work on non-KDBUS systems either (at least not without adaptation)
    3. If you want to write multiplatform software that is extremely depandable on IPC, you'll either have to abstract away the IPC differences or use DBUS1. Same as with virtually any other OS out there (AFAIK, no one uses Windows' COM IPC for multiplatform software either).

    Leave a comment:


  • nslay
    replied
    You're wrong about portability. There are some things Unix-like IPC can do that Windows IPC can never do (and very likely vice versa). The capabilities of AF_UNIX/AF_LOCAL sockets are NOT possible in Windows. And this, for example, is why tmux will NEVER run on Windows even with Cygwin support. NEVER. It will never be portable to Windows. EVER!
    EDIT: Well, apparently tmux now does run on Cygwin. It didn't work last time I compiled it on Cygwin. And looking at the source code, it doesn't appear to use AF_UNIX/AF_LOCAL's special ability to send file descriptors to other processes (which is the part that is not possible on Windows).

    The examples don't stop there either. Another easy one is lazy memory mapping of files. Unix-like systems can do it. You can map 2TB of memory to a file without actually needing 2TB of RAM, swap or even disk space. Windows can do memory mapping to a file but insists guaranteeing physically-backed space. I ran into this issue playing with Caffe and LMDB (Caffe or whatever was opening a 2TB memory mapped file database even if it was empty!).

    Depending on what BUS1 will do, it may very well be impossible for other Unix-like systems (or even Cygwin) to ever run software that uses it. The capabilities in those other Unix-like systems may not translate well or even exist! It may require extensive changes to a kernel to support BUS1!

    The nice thing about KDBUS was that it supposedly resembled DBUS ... and a lot of software already uses DBUS. DBUS runs on every Unix-like system I can think of. It made a lot of sense to try to use DBUS since it's almost kind of like a standard. But no, these guys want to make a brand new IPC potentially screwing over every other Unix-like system out there. It wouldn't be the first time either (ALSA is my favorite example).

    Last edited by nslay; 15 December 2015, 12:11 AM.

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by Dharc View Post

    your point is wrong just a few more examples. bhyve is portable, I heard about bring it in Dragonfly times ago. HAMMER2 has portability in mind instead HAMMER and there was effort to bring it in OpenBSD in last GSoC. FreeBSD's make is the same of NetBSD and it is original from NetBSD, NetBSD folks do portable things, that's why bmake is used by default in FreeBSD, so they share codes. FreeBSD's pkg main developer pay attention on keeping portable pkg for Dragonfly (so they share codes and waste time with others), Darwin and Linux too. Dragonfly DPorts is built from FreeBSD Ports and FreeBSD Ports team accept Dragonfly patches to ease Dragonfly team. Illumos, System V derivative not a BSD, is replacing GRUB for FreeBSD bootloader. so you're wrong.

    they are not fully POSIX and SUS compliant, but they are enough for each OS share codes easily.
    again you are mixing portability with collaborative Multiplatform development and compatibility.

    Portability: is a language implementation issue, as far as ASM, C, C++ goes everything is portable, for example i can mix features L4 kernel with Apple Mach 3.0 IPC and make it run on Windows XP using userspace DCOM while emulating BSD jails for fun natively on the NT kernel, it will be worth it? or easy? or hard? non-idiotic? that will be another issue but is portable!!!

    Compatibility: Refers mostly to an stable API that makes trivial run software on platform that implement this API correctly, for example any application written using only ISO C99 should run on any platform that comply with this standard, hence is compatible.

    Collaborative Multiplatform Development: refers as involved third parties develop code with multiple platforms/Toolkits/API in mind as the project goal and is set as a requirement at such, for example libevent won't take a patch that make linux faster but breaks compilation or generate incompatible structures on other OS without a very good technical reason, accepting patches from other project to make certain features available in that specific project is not collaborative, at best is good manners from upstream as long is not intrusive to the focus of the project.

    In the Unix and Unix like kernel projects only number one applies, is every men on its own(kernel in this case) out there, hence no one in the BSD camp will port a feature to Linux and Linux will not port a feature to anything outside linux, the same DragonFly won't port the VFS layer to any other BSD or linux. etc.

    so, Again.

    1.) Byhve don't work at all on Linux, can't compile, can't even apply a patch, don't uses linux compatible headers outside few general posix one, it won't work on a linux kernel and it makes no sense since is basically the BSD licensed version of KVM(typical "is not my license" FreeBSD version of NIH syndrome), any FreeBSD system with Bhyve can run linux as a Guest in the same sense any KVM linux system can run BSD as a guest. I'll close this topic unless you show me at least an screenshot on bhyve kernel modules loading on a linux kernel

    2.) Hammer and Hammer2 require changes in VFS layers that will break stuff for other Unix FS, Hammer2 still require this VFS layer modifications and is halfway designed but is seems its trying to abstract certain parts to allow certain features that by causality improve other Unixes "ability" to adapt it when possible(so far i haven't heard of anyone actually making it real, some have tried in OpenBSD and Freebsd use it once as a April 1st joke), for now it requires exclusively a dragonflyBSD kernel, it can be ported yes but is on the interested party to do it, they won't.

    3.) bmake and many other things mentioned here are not kernel community related projects and those live in user space and in the case of bmake the project site clearly cites "bmake is derived from NetBSD's make(1), its goal is to be a portable version of same", so again this points are moot when you are discussing that a kernel IPC will break compatibility with other kernels.

    4.) Grub case on BSD is a license issue mostly, pretty much the same thing happened with GCC and GLANG and many other duplicated projects on the BSD side related to "muah muah muah is not BSD licensed" but as far as i got it, some issues still stand since this project need also to migrate to CLANG/libc++ toolset since they are still stucked with gcc-4.2.1 due to the license, so it will happen eventually but again neither 2 or 3 apply since FreeBSD boot loader was made to boot FreeBSD, anything else need porting and hooks where Grub2 is an external project and is designed to boot anything that can be booted

    To close this, is irrelevant if Linux get an IPC or not since any application/library/toolkit that work on both today require extensive enough porting as it is and in many case this won't expose certain features outside certain OS/kernel or at best in the API documentation exist warnings, so you know certain features in certain kernel are very problematic and shouldn't be used in production

    Leave a comment:


  • jrch2k8
    replied
    Originally posted by Dharc View Post

    your point is wrong just a few more examples. bhyve is portable, I heard about bring it in Dragonfly times ago. HAMMER2 has portability in mind instead HAMMER and there was effort to bring it in OpenBSD in last GSoC. FreeBSD's make is the same of NetBSD and it is original from NetBSD, NetBSD folks do portable things, that's why bmake is used by default in FreeBSD, so they share codes. FreeBSD's pkg main developer pay attention on keeping portable pkg for Dragonfly (so they share codes and waste time with others), Darwin and Linux too. Dragonfly DPorts is built from FreeBSD Ports and FreeBSD Ports team accept Dragonfly patches to ease Dragonfly team. Illumos, System V derivative not a BSD, is replacing GRUB for FreeBSD bootloader. so you're wrong.

    they are not fully POSIX and SUS compliant, but they are enough for each OS share codes easily.
    again you are mixing portability with collaborative Multiplatform development and compatibility.

    Portability: is a language implementation issue, as far as ASM, C, C++ goes everything is portable, for example i can mix features L4 kernel with Apple Mach 3.0 IPC and make it run on Windows XP using userspace DCOM while emulating BSD jails for fun natively on the NT kernel, it will be worth it? or easy? or hard? non-idiotic? that will be another issue but is portable!!!

    Compatibility: Refers mostly to an stable API that makes trivial run software on platform that implement this API correctly, for example any application written using only ISO C99 should run on any platform that comply with this standard, hence is compatible.

    Collaborative Multiplatform Development: refers as involved third parties develop code with multiple platforms/Toolkits/API in mind as the project goal and is set as a requirement at such, for example libevent won't take a patch that make linux faster but breaks compilation or generate incompatible structures on other OS without a very good technical reason, accepting patches from other project to make certain features available in that specific project is not collaborative, at best is good manners from upstream as long is not intrusive to the focus of the project.

    In the Unix and Unix like kernel projects only number one applies, is every men on its own(kernel in this case) out there, hence no one in the BSD camp will port a feature to Linux and Linux will not port a feature to anything outside linux, the same DragonFly won't port the VFS layer to any other BSD or linux. etc.

    so, Again.

    1.) Byhve don't work at all on Linux, can't compile, can't even apply a patch, don't uses linux compatible headers outside few general posix one, it won't work on a linux kernel and it makes no sense since is basically the BSD licensed version of KVM(typical "is not my license" FreeBSD version of NIH syndrome), any FreeBSD system with Bhyve can run linux as a Guest in the same sense any KVM linux system can run BSD as a guest. I'll close this topic unless you show me at least an screenshot on bhyve kernel modules loading on a linux kernel

    2.) Hammer and Hammer2 require changes in VFS layers that will break stuff for other Unix FS, Hammer2 still require this VFS layer modifications and is halfway designed but is seems its trying to abstract certain parts to allow certain features that by causality improve other Unixes "ability" to adapt it when possible(so far i haven't heard of anyone actually making it real, some have tried in OpenBSD and Freebsd use it once as a April 1st joke), for now it requires exclusively a dragonflyBSD kernel, it can be ported yes but is on the interested party to do it, they won't.

    3.) bmake and many other things mentioned here are not kernel community related projects and those live in user space and in the case of bmake the project site clearly cites "bmake is derived from NetBSD's make(1), its goal is to be a portable version of same", so again this points are moot when you are discussing that a kernel IPC will break compatibility with other kernels.

    4.) Grub case on BSD is a license issue mostly, pretty much the same thing happened with GCC and GLANG and many other duplicated projects on the BSD side related to "muah muah muah is not BSD licensed" but as far as i got it, some issues still stand since this project need also to migrate to CLANG/libc++ toolset since they are still stucked with gcc-4.2.1 due to the license, so it will happen eventually but again neither 2 or 3 apply since FreeBSD boot loader was made to boot FreeBSD, anything else need porting and hooks where Grub2 is an external project and is designed to boot anything that can be booted

    To close this, is irrelevant if Linux get an IPC or not since any application/library/toolkit that work on both today require extensive enough porting as it is and in many case this won't expose certain features outside certain OS/kernel or at best in the API documentation exist warnings, so you know certain features in certain kernel are very problematic and shouldn't be used in production

    Leave a comment:

Working...
X