Slashdot Mirror

← Back to Stories (view on slashdot.org)

Kernel DBus Now Boots With Systemd On Fedora

Posted by timothy on from the trying-new-things dept.

An anonymous reader writes "Red Hat developers doing some holiday hacking have managed to get a bootable system with systemd + KDBUS on Fedora 20. KDBUS is a new DBus implementation for the Linux kernel that provides greater security and better performance than the DBus daemon in user-space. Systemd in turn interfaces with KDBUS for user-space interaction. Testing was done on Fedora 20 but the systemd + KDBUS configuration should work on any modern distribution when using the newest code."

8 of 341 comments (clear)

  1. Why, oh why? by Anonymous Coward · · Score: 5, Insightful

    Why do we need in-kernel DBUS implementation. And please don't tell me about performance, lot's of software with much higher performance requirements is more than happy in userland...

    1. Re:Why, oh why? by Anonymous Coward · · Score: 4, Insightful

      We don't need in-kernel DBUS. Userland can run such things just fine. Is there a "need for speed" and prompt response? Well, so raise priority of the userland dbus daemon then. Right up to real-time priority if need be. That works for jack, which have real-time constraints that can be hard to meet. It works for robot control software. So surely a userland approach will work for something as benign as dbus.

      You can even run a linux system without any dbus at all - it is definitely not needed in the kernel.

  2. More Bloat ? by fluffy99 · · Score: 5, Insightful

    Why is this NOT another example of kernel bloat, and the opposite direcion they should be heading (ie getting user stuff out of the kernel)? Seems like the primary use of D-BUS is for the desktop components, which already abuse/overuse inter-process communication. The "huge performance improvement" is only for those processes that shouldn't be abusing this anyway.

  3. Re: "Slashmirrored" by Desler · · Score: 4, Insightful

    Btw: Why is KDBUS code full with 'goto' calls ?

    For the same reason the kernel uses them. Because they aren't mindless ideologues.

  4. Re: "Slashmirrored" by sjames · · Score: 4, Insightful

    Actually, overall I would prefer sticking with /etc/rc[1-5]. It is simple and functional.

    All the new crap strikes me as some combination of fixing what's not broken and a solution desperately seeking a problem.

  5. Re:So this is the thing killing portability by olau · · Score: 4, Insightful

    You, sir, are a confused person. The protocol is open and free for any other OS to implement, and will remain so.

    If the BSDs are left in the dust, it's because they're lacking the manpower to do the things a new GUI needs. This was not a big problem for GNOME 2, which is architecturally more than a decade old. But things have changed.

    I can understand if people disagree with the path the GNOME developers have chosen because it does not fit with their ideals - but you have to understand that these developers are not your serfs you can command. There are still plenty of GUI environments with modest requirements of the OS, and while they may not do the same things you can choose from any of them as you wish. So quit the whining.

  6. Re:So this is the thing killing portability by Flammon · · Score: 4, Insightful

    There's already a D-Bus implementation available on BSD and other Unices. The API is documented and anyone has the freedom to implement it any way they want, userspace, kernelspace or outerspace.

    I fail to see how one more implementation, more specfically the Linux kernel one, has anything to do with giving up on anything.

    --
    ayottesoftware.com
  7. Re: "Slashmirrored" by Desler · · Score: 5, Insightful

    Nope, it's because gotos are very nice for error handling over rats nests of if/else. Which is what its predominate use in the kernel is.