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

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

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

    While KDBUS has yet to be mainlined as it was sent back to the drawing board, at least some of the systemd developers are working on a new kernel bus implementation called BUS1...

    http://www.phoronix.com/scan.php?pag...In-Development

  • #2
    I really was hoping for this. Maybe it will be a much better start than KDBUS

    Comment


    • #3
      inb4 someone says "Hur dur port Plumber and 9P from Plan 9".

      Comment


      • #4
        STREAMS is the most suitable for a kernel level IPC, but, looking at the implementation, its not as stupidly complex as D-BUS. Lets hope it stays this way.

        Comment


        • #5
          Why not just use TIPC... It's in-kernel now

          Comment


          • #6
            Good thing too. More and more people are starting to resent the systemd team for constantly forcing completely retarded junk on people. Maybe they finally realized that.

            Comment


            • #7
              I hope it will end up providing only the minimal set of things that only the kernel can provide, maximizing cache coherence, minimizing context switching, basic security, leaving everything else to userland, and exposing a userland interface which can be implemented on any OS, even if the set of features does not provide a complete solution to anything, as long as it makes it easy for userland to implement a complete solution efficiently and securely.

              Comment


              • #8
                Originally posted by Hibiki Kanzaki View Post
                ...and exposing a userland interface which can be implemented on any OS, even if the set of features does not provide a complete solution to anything, as long as it makes it easy for userland to implement a complete solution efficiently and securely...
                I don't think its the job of linux kernel developers to also write alternate versions of their features for other kernels. If such features are easy to write in userland, they should not be in the kernel anyway.

                (at one time there was an expectation of the DRI developers to have a fully portal interface implementing the drivers for all UNIX type systems. That didn't improve the UNIX type systems much, but hold Linux back. Now these features are put into Linux first and the other kernels are free to port them.)

                Comment


                • #9
                  Sure, why not? You've made your own shell, sound API, display server and protocol, your own init system, what harm is there adding yet another non-Unix technology to Linux?

                  Comment


                  • #10
                    Originally posted by Hibiki Kanzaki View Post
                    I hope it will end up providing only the minimal set of things that only the kernel can provide, maximizing cache coherence, minimizing context switching, basic security, leaving everything else to userland, and exposing a userland interface which can be implemented on any OS, even if the set of features does not provide a complete solution to anything, as long as it makes it easy for userland to implement a complete solution efficiently and securely.
                    Yeah, that's the thing I don't get... Why does kdbus switch contexts so much? If the goal was to develop the most ineffective message buss possible then kdbus would be that exactly. What the hell were they thinking? Probably something along the lines of, "if we context switch as much as possible we can make an artificial perception that SMT improves performance!"

                    Comment

                    Working...
                    X