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."

13 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 armanox · · Score: 4, Informative

      Canonical is innocent - it's Red Hat's doing. Just like Pulseaudio and a million other innovations (some good, some less then good). But Red Hat has had a hand in most of the desktop development that people see.

      --
      I'm starting to think GNU is the problem with "GNU/Linux" these days.
    2. 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.

    3. Re:Why, oh why? by Sri+Ramkrishna · · Score: 4, Informative

      KDbus is being done by Greg K-H of Linux Foundation. There are some good reasons for having a kernel bus. The first rev was killed, but the second rev is being worked on. Linus has already signed off on getting this integrated. It's just a matter of working out the details. A lot of this is driven by desktop projects, so things like smooth transition to a login screen, wayland, application sandboxing are good reasons to have it.

  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 SumDog · · Score: 4, Interesting

    My first experience with systemd was on OpenSUSE. Although it seems like a good idea, it seems to add some unneeded complexity. /etc/init.d/someservice restart now redirect to systemctl, with no real output. Oh I have to run status to see if it succeeded. Now I have to use journalctl to see why it failed.

    I'm all for dependency based init systems, but I feel Gentoo got that right with OpenRC. It gets rid of all that rc1,2,3,4,5 crap while keeping the /etc/init.d/ structure we're familiar with.

    Gentoo can not be setup to use systemd too. I guess it's now the future; better get use to it.

  4. 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.

  5. 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.

  6. 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.

  7. 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
  8. 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.

  9. Too much navel gazing by Sri+Ramkrishna · · Score: 5, Interesting
    Too much navel gazing about change. Here is the reason behind kdbus. Primarily it's for application sandboxing and making sure that a bad actor does not do something bad to something else. As GNU/Linux gets more popular, we want to be able to make sure that we can contain bad actors as much as possible. It's also a step in the direction to have a universal app spec instead of having to have each distro package the same damn app. I miean, how much duplicate work do you want to do? It makes it easier for people who write apps to have GNU/Linux as a target instead of having to pick the most popular distro at that point of time.

    http://lwn.net/Articles/551969/

    Linus is okay with it. Have to worry about Al Viro. :-)

    Here is an updated talk by Greg K-H that he gave on KDbus, he posted this about 3 days ago. https://github.com/gregkh/presentation-kdbus

    Let's stop all the FUD, and educate yourself on the reasons behind on this.

  10. Re: "Slashmirrored" by PlusFiveTroll · · Score: 4, Informative

    Even on fast SSDs I've never seen 8 cold boot it in 3 seconds. 9-12ish maybe. Add in windows networking and it's much slower. Also Windows delays a lot of tasks so you are to the GUI but your actual services are not running yet. In the server market your boot speed is highly dependent on network resource dependencies with varying delays.