Forgot your password?
typodupeerror
Operating Systems Red Hat Software Linux

Kernel DBus Now Boots With Systemd On Fedora 341

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

Kernel DBus Now Boots With Systemd On Fedora

Comments Filter:
  • "Slashmirrored" (Score:2, Insightful)

    by Anonymous Coward

    So do we just mirror phoronix on slashdot, now?

  • Why, oh why? (Score:5, Insightful)

    by Anonymous Coward on Sunday December 29, 2013 @04:21PM (#45813275)

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

    • Re: (Score:3, Funny)

      by fisted (2295862)
      Because GNU!

      Fortunately, the BSD world is much less insane.
      • Re:Why, oh why? (Score:4, Insightful)

        by x_t0ken_407 (2716535) on Sunday December 29, 2013 @06:25PM (#45813945) Homepage
        Amen to that. I was mildly irritated when I first saw systemd take over Fedora (I forget what release it was), so I moved to Arch Linux -- which I figured I could count on to be the Unix-like system I always loved and forever adhere to the K.I.S.S. philosophy...then they ALSO shoved systemd down our throats. Have been using FreeBSD on the desktop [where practical] ever since; it was already what I used on my servers.
        • gentoo, or something gentoo based, like sabayon?
          • by dpilot (134227)

            Gentoo is currently pushing over to systemd. About a month ago they set stable keywords for gnome-3.8 and systemd, so that pretty much everyone who uses any gnome software, not just the gnome desktop, got pushed to systemd as well.

            There is not any official word, but that was what happened. It's still possible to run an OpenRC system, but it takes a fair amount of work. The forums still have systemd migration problems, a month later.

            There was an item on the Gentoo Bugzilla for upstart, but that was recent

        • Re: (Score:3, Interesting)

          I'm just gonna leave this here.

          https://plus.google.com/111049168280159033135/posts/4KJxFY8VvT1 [google.com]

    • Re:Why, oh why? (Score:4, Insightful)

      by Anonymous Coward on Sunday December 29, 2013 @04:44PM (#45813383)

      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.

      • Re:Why, oh why? (Score:4, Interesting)

        by jcdr (178250) on Sunday December 29, 2013 @05:28PM (#45813617)

        I good reason is the future possibility to manage kernel features in a more formal way than with the /proc or /sys interfaces.

        It has taken about a decade to bring a standard IPC protocol to Linux. I mean a protocol that truly work between applications from different team of developers.It's now time to use it from a wider audience. Making it part of the kernel not only make it a bit more fast, but it clearly make it a more appealing choice for applications that need IPC.

        • Re:Why, oh why? (Score:4, Interesting)

          by multi io (640409) <olaf.klischat@googlemail.com> on Sunday December 29, 2013 @09:21PM (#45815029)

          I good reason is the future possibility to manage kernel features in a more formal way than with the /proc or /sys interfaces.

          What's wrong with /proc and /sys for kernel and hardware configuration tasks? It's easy and twekable, you can poke around in it without writing a program first, and it conforms to "everything is a file".

          It has taken about a decade to bring a standard IPC protocol to Linux. I mean a protocol that truly work between applications from different team of developers.It's now time to use it from a wider audience. Making it part of the kernel not only make it a bit more fast, but it clearly make it a more appealing choice for applications that need IPC.

          IPC is between processes, not between a process and the kernel.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      Lennart Poettering, nothing he touches is easy to remove once it has a foothold. And it seems everyone who packages it is drinking the same coolaid. Sometime I wonder if packaging tools should have a 'shit can list' that allows packages to be block per developer.

      Just blocking this guy would prevent pulseaudio, systemd and avahi.

    • KDBUS sounds okay to me. Apparently it, in a lot of people's views, boils down to "DBUS done right" -- the protocol is completely different under-the-hood, and will be (or is intended to be, if the userspace side people don't fuck it up like they constantly do to udev) supported in userspace by a translation layer for old-DBUS programs.

      Further, the kernel devs have a habit (substantially creditable to Linus Torvalds) of doing a lot of things right, and making sure they don't break anything in the process, s

  • More Bloat ? (Score:5, Insightful)

    by fluffy99 (870997) on Sunday December 29, 2013 @04:31PM (#45813319)

    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.

    • by jcdr (178250)

      Seems like the primary use of D-BUS is for the desktop components, which already abuse/overuse inter-process communication.

      DBUS is already used on a number of embedded projects since many years.

    • Re:More Bloat ? (Score:4, Informative)

      by salahx (100975) on Sunday December 29, 2013 @07:34PM (#45814427)

      hHe short version: http://lwn.net/Articles/551969/ [lwn.net]

      At first, this sounds like the kernel developers have raided LP's [wikipedia.org] "private stash", but it turns out the reason for kdbus is preceeds it - in fact in even preceeds d-bus itself. Specifcally, kdbus is intended to be a alternative version of Android's binder. Android doesn't use d-bus, because it didn't exist (or was too immature) back when it was concieved. While binder is in the staging tree, it'll never be part of the kernel proper for various - some fixable, other unfixable. Binder is not just a hard pill to swallow for the kernel developer, its a spiked ball the size of a fist in a bottle labelled "NOT TO BE TAKEN ORALLY".

      There's a NEED for something like kdbus independt of systemd. We needs a new IPC type, like domain sockets, except with reliable multicast and filtering. Linux domain sockets do not support multicast, much elss reliable multicast. Approaches to add this have been tried: Both by directly adding multicast to domain sockets or by adding an ew address family (AF_DBUS), but patches adding that to unix domain sockets have been rejected, as has AF_DBUS.

      No one suggesting putting the entire dbus-daemonm and protocol in the kernel with kernel XML parser (and so dbus-daemon will still be needed for authentication and the inital connection setup, but then steps out of the way after that), kdbus is "just enough" to implement an accelerated and robust message bus.

  • by Improv (2467) <pgunn@dachte.org> on Sunday December 29, 2013 @04:44PM (#45813385) Homepage Journal

    The corruption of GNOME and other opensource projects by tying it specifically to Linux comes with this; it represents giving up on being cross-platform, giving up on the BSDs and other Unices, and giving up on openness. No thanks.

    • by AceJohnny (253840)

      Portability also means giving up on system-specific optimizations and features. Some people have decided that Linux's market share means it's time to bank on those optimizations. Why not?

    • by olau (314197) on Sunday December 29, 2013 @05:14PM (#45813557) Homepage

      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.

      • by Jah-Wren Ryel (80510) on Sunday December 29, 2013 @05:31PM (#45813629)

        you have to understand that these developers are not your serfs you can command

        Ugh, I hate that sort of extremist straw-man. The developers are working on public projects, that means they are subject to both public praise and public criticism. It is a package deal.

      • by Improv (2467)

        Then we should turn away from GNOME3. Because they're taking compatibility lightly. Because they're wrongheaded. We should make sure that no distros ship GNOME3 or systemd as default. Sure, they're not serfs, they're just people promoting an inferiour solution that damages Unix.

    • by Flammon (4726) on Sunday December 29, 2013 @05:36PM (#45813669) Homepage Journal

      There's already a D-Bus implementation available on BSD and other Unices. The API is documented [freedesktop.org] 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.

    • by fnj (64210)

      I don't see giving up on openness, but yes, it represents a cavalier kiss-off to BSD. Developer privilege. And it is user privilege to turn one's back on this.

    • What will you do?
    • by jcdr (178250)

      You forgot that Linux was created precisely because there was no truly open UNIX running on a PC a his time. Even 386BSD arrived after Linux started to gain a growing community. The Linux community always tried a lot of different approach, and this is the reason why it is do dominant today.

      But I agree that Linux is more and more a norm by itself and that his UNIX part is slowly mutating into a simple compatibility interface layer. I am not even surprised about that since UNIX was created at his time for har

  • Listen to A.S.T. (Score:3, Interesting)

    by Bram Stolk (24781) on Sunday December 29, 2013 @04:54PM (#45813437) Homepage

    Andrew S. Tanenbaum had a point about Linux not being micro kernel.
    This is getting crazy: moving perfectly fine userland systems to the kernel.
    Isn't the kernel large enough already?

    • Re: (Score:3, Informative)

      by Anonymous Coward

      Andrew S. Tanenbaum had a point about Linux not being micro kernel.
      This is getting crazy: moving perfectly fine userland systems to the kernel.
      Isn't the kernel large enough already?

      That word does not mean what you think it means. In fact, kernel dbus is probably the most microkernel-ish feature I've seen added to the Linux kernel (although I haven't been paying close attention).

      A microkernel is defined as a kernel composed of a large number of very loosely coupled modules, with an absolute minimum of functionality in the modules that are loaded initially or by the bootloader. Because of this, microkernels tend to have slightly greater overhead (both processing and memory) than compara

    • I agree that Linux isn't a microkernel, but I don't think adding an IPC framework like KDBUS to Linux makes it bloated compared to a microkernel. I believe that an IPC system is the one thing that all microkernels include. Including an IPC framework in the kernel should help move other functionality from the kernel to standalone user space process that expose services over IPC.

  • by Sri Ramkrishna (1856) <.moc.liamg. .ta. .anhsirkmar.marirs.> on Sunday December 29, 2013 @07:07PM (#45814229)
    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/ [lwn.net]

    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 [github.com]

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

  • why not give up on dbus, and just use binder, which is already supported in the kernel?

    Personally, I _do not want_ this.

    While, we are at it, I do not want do-everything daemons like upstart or systemd. These monolithic programs of undefined scope are poor examples of software engineering, and not needed.

  • by markhahn (122033) on Sunday December 29, 2013 @08:46PM (#45814849)

    The really really stupid thing is that desktop isn't even the reason why Linux. Obviously no server needs dbus let alone kdbus, and plenty of desktops don't either. Yes, it's amusing that I get a popup when I plug in a USB stick, but is that essential functionality? Sure, some very simple form of event multicast would be good, but is this it?

    Everything LP touches seems to epitomize rebellion against, or ignorance of, the *nix/OSS philosophy (you know, modularity, loosely joined, liberal-in-what-you-accept, etc). systemd is the USSR of rc systems. pulse only remains because apps can still bypass it.

"Maintain an awareness for contribution -- to your schedule, your project, our company." -- A Group of Employees

Working...