Announcement

Collapse
No announcement yet.

The Heated KDBUS Debate For The Linux Kernel Has Fizzled Out

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

  • #11
    Originally posted by Delgarde View Post

    In theory, perhaps. But it suffers from one big flaw - namely, that almost nobody actually uses it, whereas D-Bus has been the IPC mechanism of choice on Linux for the past decade. Technical superiority (real or imagined) has only passing relevance to which technology actually wins.
    You are right, but it's kinda sad that's how it is. dbus is more than just an ipc, and not a good one at that. It's a shame that we have to be stuck with it in the future only because we are already stuck with it.

    The real truth is, sometimes you have to let bygones be bygones. But, most people don't care what the real truth is.

    Comment


    • #12
      Someone with the right knowledge should step up with a design for a general-purpose kernel IPC mechanism, like DBUS but taking all the feedback into account.

      It's not every day the kernel needs a major new API that would have such broad usage, potential ports to other OS's like BSD, etc - that's something you could be really proud of, that goes far beyond patches to some driver or whatever. I'm sure the kernel dev's would help refine any proposal. If your work does get accepted, it would be so good on the resume that it would probably guarantee you jobs for life?

      Comment


      • #13
        dbus is for passing msgs between desktop applications (OO primarily), and for that it works now
        transferring bulk data or something in real time requires a specialized IPC protocol, always has, always will

        current bottleneck of dbus is its server, not context switching

        Comment


        • #14
          Originally posted by uid313 View Post
          Plumber, the IPC system from Plan 9 from Bell Labs is superior to D-Bus.
          KDBUS is implemented as a socket type, reached by AF_DBUS.
          Plumber is much simplier and you just read/write to a virtual file on the file system.

          Hence Plumber is more Unix, in the way that it follows the Unix philosophy "everything is a file".
          Also, since remote file systems may be mounted (done using 9P on Plan 9) it is also network transparent.

          https://lists.debian.org/debian-user.../msg00802.html
          Your info are outdated. Kdbus is implemented as a filesystem probably from the V2 or V3, for sure in the GIT PULL version.

          Comment


          • #15
            Originally posted by gens View Post
            dbus is for passing msgs between desktop applications (OO primarily), and for that it works now
            transferring bulk data or something in real time requires a specialized IPC protocol, always has, always will

            current bottleneck of dbus is its server, not context switching
            Hello, I think phoronix is missing two important postings in first week of May to lkml:
            http://lkml.iu.edu/hypermail/linux/k...5.0/00678.html
            http://lkml.iu.edu/hypermail/linux/k...5.0/01551.html
            There Havoc Pennington, one of the main developers of dbus
            http://en.wikipedia.org/wiki/Havoc_Pennington admits that dbus is a hack
            (which kdbus is based on) compared to real capability-based IPCs such as
            COM and Binder. Quoting Havoc:
            "I guess you're really asking how all this relates to capabilities and
            I don't know - dbus only looks at processes, not objects, for security
            purposes, as far as I know. Objects are just a convention, the dbus
            daemon doesn't actually care how a process interprets the object path
            (or interface or method name, for that matter)."

            Comment


            • #16
              The LKML is looking more and more like the US Congress, when a change is clearly needed yet the congressmen are the only ones not getting it and arguing for years.

              Comment


              • #17
                Originally posted by mark45 View Post
                The LKML is looking more and more like the US Congress, when a change is clearly needed yet the congressmen are the only ones not getting it and arguing for years.
                afaik the US Congress makes decisions only based on money
                too bad you cant lobby Linus

                Comment


                • #18
                  Originally posted by gens View Post

                  afaik the US Congress makes decisions only based on money
                  too bad you cant lobby Linus
                  which is Redhats real issue. the "linux community" was an easy one to get onto their side, not even needed much money; just some well played shitstorms and forced dramas against easy targets and opponents like canonical.

                  Comment


                  • #19
                    Originally posted by k1l_ View Post
                    which is Redhats real issue. the "linux community" was an easy one to get onto their side, not even needed much money; just some well played shitstorms and forced dramas against easy targets and opponents like canonical.
                    to be honest, i think the push is more from passion of a few systemd devs
                    then again all of what they want can be done by fixing up the dbus daemon

                    but ye, just put "red-hat engineer" on something and the crowd goes wild

                    Comment


                    • #20
                      Originally posted by phrx_reader View Post

                      Hello, I think phoronix is missing two important postings in first week of May to lkml:
                      http://lkml.iu.edu/hypermail/linux/k...5.0/00678.html
                      http://lkml.iu.edu/hypermail/linux/k...5.0/01551.html
                      There Havoc Pennington, one of the main developers of dbus
                      http://en.wikipedia.org/wiki/Havoc_Pennington admits that dbus is a hack
                      (which kdbus is based on) compared to real capability-based IPCs such as
                      COM and Binder. Quoting Havoc:
                      "I guess you're really asking how all this relates to capabilities and
                      I don't know - dbus only looks at processes, not objects, for security
                      purposes, as far as I know. Objects are just a convention, the dbus
                      daemon doesn't actually care how a process interprets the object path
                      (or interface or method name, for that matter)."
                      i'm guessing you didn't understand or didn't read the rest. this is complete opposite from being hack and makes total sense.

                      read this
                      Anyhow... so the big picture is this different design emphasis. dbus
                      is solving multicast/singleton/multi-process first, and then making it
                      look sort of OO-ish in the language binding library. COM is solving
                      "C++ has an impoverished runtime with a fragile ABI" first, and then
                      bolting on "hey we could make these fancied-up objects be out of
                      process sometimes."
                      and
                      dbus is exposing more implementation detail than COM - it explicitly
                      is always about processes (ok, technically bus connections, but the
                      point is: not objects). You can track the processes themselves (via
                      the bus names). dbus encourages writing async code, again exposing
                      that we're dealing with remote objects. dbus encourages you to just
                      use your language's native runtime for in-proc objects.
                      Havoc is not saying that dbus is a hack, he says design and goal were different from COM and Binder (which he was asked about in comparison to dbus) for various reasons. mainly flexibility. and if you ever coded with COM, Binder and dbus you'd see why dbus is so much better to use in code
                      Last edited by justmy2cents; 14 May 2015, 04:20 PM.

                      Comment

                      Working...
                      X