Announcement

Collapse
No announcement yet.

Systemd 221 Fixes Bugs, Wants Distributions To Start Shipping KDBUS

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

  • #11
    Originally posted by duby229 View Post

    It's supposed to be a message passing system. So that you don't need to develop specific interfaces for different components to talk to each other. The problem is that it's gigantic and does waaaaaay more than that and the message passing sucks ass.

    The biggest legitimate complaint I've read from developers is that the code style sucks. It's really hard to understand the code.
    No the complaint is that it is insecure and they refused to fix it properly.
    So now there will be insecure code sitting unused in the kernel waiting to be exploited down the road because SYSTEMD decided for you.

    Comment


    • #12
      Originally posted by Azrael5 View Post
      What is exactly KDBUS? What is its function!?
      It's a rewrite of the D-Bus IPC system that redistributes the core message-passing functionality currently handled by the D-Bus daemon into the kernel and a libdbus replacement. The benefits are:

      • Fewer context switches ("sender, kernel, receiver" rather than "sender, kernel, d-bus daemon, kernel, receiver")
      • Improved security (There are various things only the kernel can guarantee)
      • Support for zero-copy message passing to make bulk data transfers feasible (there's overhead, so it only switches on when the message size is above a certain limit)
      • Available earlier in the boot process and later in the shutdown process (simplifies certain cases where either functionality would be nice to have but can't be because D-Bus isn't up yet/still or two different solutions have to be maintained)



      Initially, there was some bikeshedding that boils down to "I don't think the kernel should gain another IPC mechanism until everyone in userland rewrites their software to conform to my architectural vision" but Linus Torvalds has been ignoring these since it became clear that's what they were. The main hold-up now seems to be focused around seeing how much ugliness can be shaved off stuff that has to be at least a bit ugly to meet userland's requirements.

      Comment


      • #13
        I'm curious what advantages brings k-dbus for systemd, if someone knows?

        Comment


        • #14
          Originally posted by toyotabedzrock View Post
          No the complaint is that it is insecure and they refused to fix it properly.
          So now there will be insecure code sitting unused in the kernel waiting to be exploited down the road because SYSTEMD decided for you.
          Same difference.

          Comment


          • #15
            Originally posted by toyotabedzrock View Post
            No the complaint is that it is insecure and they refused to fix it properly.
            So now there will be insecure code sitting unused in the kernel waiting to be exploited down the road because SYSTEMD decided for you.
            That is funny. How again has systemd decided that kdbus is suddenly in the kernel? Isn't that up to Linus Torvalds to decide that? Didn't see him accepting it, so far.

            And how again is it unused if systemd uses it and delivers shims so that any DBUS software can use it?

            Comment


            • #16
              I think there is a decent article on lwn regarding kdbus

              Comment


              • #17
                Originally posted by ssokolow View Post

                It's a rewrite of the D-Bus IPC system that redistributes the core message-passing functionality currently handled by the D-Bus daemon into the kernel and a libdbus replacement. The benefits are:

                • Fewer context switches ("sender, kernel, receiver" rather than "sender, kernel, d-bus daemon, kernel, receiver")
                • Improved security (There are various things only the kernel can guarantee)
                • Support for zero-copy message passing to make bulk data transfers feasible (there's overhead, so it only switches on when the message size is above a certain limit)
                • Available earlier in the boot process and later in the shutdown process (simplifies certain cases where either functionality would be nice to have but can't be because D-Bus isn't up yet/still or two different solutions have to be maintained)



                Initially, there was some bikeshedding that boils down to "I don't think the kernel should gain another IPC mechanism until everyone in userland rewrites their software to conform to my architectural vision" but Linus Torvalds has been ignoring these since it became clear that's what they were. The main hold-up now seems to be focused around seeing how much ugliness can be shaved off stuff that has to be at least a bit ugly to meet userland's requirements.
                Thanks for reply.

                Comment


                • #18
                  Getting things tested in real-world situations is important. I think this is a great idea for KDBUS. Maybe distributions will discover that it crashes or that it doesn't speed things up. That would be good to know before it comes out in an official kernel release.

                  Comment


                  • #19
                    Originally posted by Zan Lynx View Post
                    Getting things tested in real-world situations is important. I think this is a great idea for KDBUS. Maybe distributions will discover that it crashes or that it doesn't speed things up. That would be good to know before it comes out in an official kernel release.
                    For that matter, I'd prefer to trust kernel developers over systemd developers every single time.

                    Comment


                    • #20
                      Originally posted by duby229 View Post

                      For that matter, I'd prefer to trust kernel developers over systemd developers every single time.
                      kdbus is created by a Linux kernel developer, GKH.

                      Comment

                      Working...
                      X