Announcement

Collapse
No announcement yet.

Fedora's Rawhide Kernel Adds In KDBUS Support, Ready For Testing

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

  • Fedora's Rawhide Kernel Adds In KDBUS Support, Ready For Testing

    Phoronix: Fedora's Rawhide Kernel Adds In KDBUS Support, Ready For Testing

    Patched into Fedora's Rawhide kernel is now KDBUS to allow users running this newest kernel package plus an updated systemd package to start trying out this in-kernel IPC mechanism...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Using sockets (i.e. AF_DBUS) seems pretty stupid when you can just use virtual files as an IPC mechanism as is done by Plumber in Plan 9 from Bell Labs.

    Because then it benefits from security through POSIX file system permissions and AppArmor, SE-Linux, etc.
    Also, its much more Unix.

    This KDBUS thing sucks.

    Comment


    • #3
      Originally posted by phoronix View Post
      Phoronix: Fedora's Rawhide Kernel Adds In KDBUS Support, Ready For Testing

      Patched into Fedora's Rawhide kernel is now KDBUS to allow users running this newest kernel package plus an updated systemd package to start trying out this in-kernel IPC mechanism...

      http://www.phoronix.com/scan.php?pag...e-Kernel-KDBUS

      To be fair, iirc KMS was also matured this way and it's pretty awesome at this point

      Comment


      • #4
        Originally posted by uid313 View Post
        Using sockets (i.e. AF_DBUS) seems pretty stupid when you can just use virtual files as an IPC mechanism as is done by Plumber in Plan 9 from Bell Labs.
        using files for ipc seems pretty stupid when all of internet is built on sockets and plan9 is dead
        Originally posted by uid313 View Post
        SE-Linux
        works for sockets
        Originally posted by uid313 View Post
        Also, its much more Unix.
        no, it is much more plan9 and much less unix (it is BSD sockets btw)
        Originally posted by uid313 View Post
        This KDBUS thing sucks.
        these plan9 and uid313 things suck
        Last edited by pal666; 30 July 2015, 03:37 PM.

        Comment


        • #5
          Originally posted by uid313 View Post
          Using sockets (i.e. AF_DBUS) seems pretty stupid when you can just use virtual files as an IPC mechanism as is done by Plumber in Plan 9 from Bell Labs.

          Because then it benefits from security through POSIX file system permissions and AppArmor, SE-Linux, etc.
          Also, its much more Unix.

          This KDBUS thing sucks.


          "Full credential information (user ID, process ID, SELinux label, control group information, capabilities, and much more) is passed with each message, and all messages carry timestamps." -- that has more security information than you can pass with POSIX file system permissions or AppArmor. I don't think a virtual file can carry owning process, cgroup and capabilities unless you encode it in the file contents directly with some kind of built in verification mechanism.

          "Messages can include timeouts ("method call windows") by which a reply must be received." - can you do that with virtual files, without encoding that information in the file?

          "The signal broadcasting mechanism has been rewritten to use bloom filters to select recipients." - can you do that with message passing to recipients using virtual files?

          "The "memfd" mechanism enables zero-copy message passing in kdbus. A memfd is simply a region of memory with a file descriptor attached to it; it operates similarly to a memory-mapped temporary file, "but also very differently." A memfd can be "sealed," after which the owning process can no longer change its contents." -- so you can send messages with kdbus that the recipient can be certain will not be modified further. Again, to do that with virtual files you would need to encode that information in the file some way - and the recipient has to hope the sender will honor their encoded pledge not to modify the file.

          "The Unix Way" is a guideline, not a command from God. The Linux kernel is monolithic, GNU HURD is "The Unix way". Git has tons of integrated features, managing your source control with rsync + rcs + sha256sum + ssh is "The Unix Way". Vim and Emacs have all sorts of fancy features, ed is "The Unix Way". ext4 filesystem has journaling, ext2 fits "The Unix Way".

          Sometimes it's worthwhile to accept additional complexity for a whole more flexible and useful than the sum of its parts.

          Comment


          • #6
            Originally posted by uid313 View Post
            Using sockets (i.e. AF_DBUS) seems pretty stupid when you can just use virtual files as an IPC mechanism as is done by Plumber in Plan 9 from Bell Labs.
            Every kdbus thread, you come in and rant about this. So tell us, if it's really that much better to use Plumber than Dbus, why is nobody actually doing so? Could it be that Plumber simply doesn't do what developers actually need from an IPC system?

            Comment


            • #7
              Originally posted by uid313 View Post
              Using sockets (i.e. AF_DBUS) seems pretty stupid when you can just use virtual files as an IPC mechanism as is done by Plumber in Plan 9 from Bell Labs.using it

              Because then it benefits from security through POSIX file system permissions and AppArmor, SE-Linux, etc.
              Also, its much more Unix.

              This KDBUS thing sucks.
              Really this summoning of Plumber/Plan9 everytime (k)dbus is mentioned is becoming a kind of running joke.

              So then if Plumber is so awesome where's the working code or tests/examples ? Where are the applications that should use this miraculous solution rather than the D-Bus turd ? Where are the astonishingly positive benchmarks of it ?
              Answer : Nothing, at least on Linux.

              It has been over 10 years since people are complaining about how terrible D-Bus is and how their imaginary perfect IPC would rock the world instead, yet we have seen nothing concrete to compete against it. So far just words and abstract concepts.

              Like it or not D-Bus is here to stay because so far nobody has been able to make a real and practical replacement for it.
              kdbus may or may not end up being a good idea, it's too early to judge as we have yet to see it in action, but at least those people are actually _doing_ something instead of just speculating like you seem to do.
              Last edited by Scias; 30 July 2015, 08:03 PM.

              Comment


              • #8
                Originally posted by Michael_S View Post



                "Full credential information (user ID, process ID, SELinux label, control group information, capabilities, and much more) is passed with each message, and all messages carry timestamps." -- that has more security information than you can pass with POSIX file system permissions or AppArmor. I don't think a virtual file can carry owning process, cgroup and capabilities unless you encode it in the file contents directly with some kind of built in verification mechanism.

                "Messages can include timeouts ("method call windows") by which a reply must be received." - can you do that with virtual files, without encoding that information in the file?

                "The signal broadcasting mechanism has been rewritten to use bloom filters to select recipients." - can you do that with message passing to recipients using virtual files?

                "The "memfd" mechanism enables zero-copy message passing in kdbus. A memfd is simply a region of memory with a file descriptor attached to it; it operates similarly to a memory-mapped temporary file, "but also very differently." A memfd can be "sealed," after which the owning process can no longer change its contents." -- so you can send messages with kdbus that the recipient can be certain will not be modified further. Again, to do that with virtual files you would need to encode that information in the file some way - and the recipient has to hope the sender will honor their encoded pledge not to modify the file.

                "The Unix Way" is a guideline, not a command from God. The Linux kernel is monolithic, GNU HURD is "The Unix way". Git has tons of integrated features, managing your source control with rsync + rcs + sha256sum + ssh is "The Unix Way". Vim and Emacs have all sorts of fancy features, ed is "The Unix Way". ext4 filesystem has journaling, ext2 fits "The Unix Way".

                Sometimes it's worthwhile to accept additional complexity for a whole more flexible and useful than the sum of its parts.
                Then you'll write scripts and end in something like git.
                Your example with git is crap, no one would use those tools like this.
                Unix way is always about combining things, but the user would never do this unless he is a developer.
                For example telepathy is relativly new and works just like this - do one job and do it well.

                Kdbus could be exposted as filesystem and would work like in plan9.

                BTW: is there a path aviable for linux 4.1?

                Comment


                • #9
                  Originally posted by Thaodan View Post
                  Then you'll write scripts and end in something like git.
                  Your example with git is crap, no one would use those tools like this.
                  That's my point. All my examples are crap. Kdbus was created because the existing simpler means for handling IPC in Linux and other Unix flavors had design limitations.

                  Originally posted by Thaodan View Post
                  Kdbus could be exposted as filesystem and would work like in plan9.
                  Again, the exposure as a filesystem reduces the benefits. You can't expose as much security information with a filesystem, you can't set expiration dates on requests for information, and you don't have a mechanism for indicating that a shared buffer is immutable. Filesystems as they exist now in POSIX don't have those features, Kdbus does.

                  To be clear, I don't have a specific attachment to the way Linux does things, or the way Linus Torvalds or Lennart Poettering do things. I think the best path forward for any free software operating system is to borrow the best possible (un-copyrighted, un-patent-encumbered) ideas it can from any possible source: VMS, FreeBSD, NetBSD, OS X, Plan 9, Amiga, even from Windows on those rare occasions Microsoft lets a good design principle slip past their marketing department. In this particular case, as far as I can tell Kdbus is something new precisely because nothing that already existed fit. No different from Linux kernel cgroups.

                  Comment


                  • #10
                    Originally posted by Michael_S View Post
                    In this particular case, as far as I can tell Kdbus is something new precisely because nothing that already existed fit. No different from Linux kernel cgroups.
                    And usage has backed that up. Both Plumber and Dbus have existed for many years - but only one of them is actually being used by a significant number of developers. One of these clearly meets a need which the other doesn't.

                    Comment

                    Working...
                    X