1. -2

For a little background, KDBUS is the kernel version of DBUS, which remains contentious and has yet to be included in the mainline kernel despite multiple attempts:




  1. 18

    This is why HackerNews doesn’t like people modifying the titles of articles.

    Reading comprehension test: Where does this email ever say “systemd requires kdbus”? Let’s break down the only parts of the email to mention kdbus.

       kdbus support is no longer compile-time optional. It is now always built-in.

    Okay, kdbus support is now wired in, so at best it’s enabled IFF my kernel supports it. Makes sense, we don’t want this stuff to bitrot waiting on kernel patches to go in.

    However, it can still be disabled at runtime using the kdbus=0 kernel
    command line setting, and that setting may be changed to default
    to off, by specifying --disable-kdbus at build-time.

    Except we have two ways to explicitly disable the wired-in kdbus support, at runtime or at build-time. So distros and/or users still don’t have to use it, even if their kernel is kbdus-enabled.

    Note though that the kernel command line setting has no effect if the
    kdbus.ko kernel module is not installed, in which case kdbus is
    (obviously) also disabled.

    …and if my kernel doesn’t load the kdbus kernel module, I also don’t get kdbus in systemd. (duh)

    We encourage all downstream distributions to
    begin testing kdbus by adding it to the kernel images in the
    development distributions, and leaving kdbus support in
    systemd enabled.

    “Please test our software under all configurations; we’d like kdbus to be default-on some day.”

    How did we get to “systemd requires kdbus” again? systemd does NOT require kdbus, that is just straight up 100% wrong. The systemd FUD machine is still going strong I see.

    1. 2

      systemd requires KDBUS to compile.

      It cannot be built without KDBUS.

      What is that if not a requirement?

      1. 4

        No, it does not require kdbus to compile. It compiles in support for kdbus, but the compiling system does not need to have kdbus available in any shape or form. Nor do you need it to run systemd.

        So no, kdbus is not required. Support for kdbus is always compiled in, but that’s not the same as kdbus being required.

        1. 2

          I can speak Spanish, but everyone I deal with on a daily basis speaks English; I rarely if ever actually get to use Spanish (a personal failing, especially since I live in California). What is the Spanish language to me?

          It’s the same with kdbus. It’s a capability of libsystemd that can be exercised at will. It’s not a requirement - if nothing uses it, it doesn’t do anything but waste a few kilobytes on your system you will not ever miss… you’re wasting more space supporting things like ancient binary formats and file system drivers for file systems nobody ever uses anymore.

      2. -4


        the git repository and bug tracking moved to github

        so, that justifies systemd throwing it’s weight around with regards to kernel development, right?

        1. 16

          From what I can tell from this announcement, kdbus support in systemd is:

          • compiled into systemd
          • disabled if your kernel does not have the kdbus module loaded
          • can be disabled using a command line option
          • the command line option can be defaulted to off at systemd compile time.

          So, if I understand correctly: if your kernel does not have kdbus support then the only impact this will have on you is that your systemd binaries might be a few Kb larger.

          I don’t see this as systemd throwing it’s weight around - more like they want to conservatively introduce a feature to a wider audience whilst, quite rightly, limiting it’s impact by placing it behind a feature flag.

          I’m having difficulty seeing this as systemd throwing it’s weight around, what did you mean by that?

          1. 5

            Thanks for your informative reply. I apologize for the tone of my comment.

            To answer your question: from the Phoronix articles linked above, and what I have read about the systemd project, I gather that the vision put forth in Revisiting How We Put Together Linux Systems has gained influence. By “throwing it’s weight around” I meant that, because the project has such influence, their decision to include kdbus could move the kernel developers to mainline it despite their serious reservations. Poettering himself explains the sd-bus API that shipped with this latest systemd release, which supports “as back-ends both classic socket-based D-Bus and kdbus.” I must admit that I have only skimmed his posts, and so I cannot summarize them.

            To the best of my ability and as time allows, I like to inspect and understand the systems that I use so that I can use them better. That may be a vain endeavor, but in it I find systemd frustrating because it adds more abstractions, the quality of which I have trouble discerning.

            1. 3

              You are correct.


              But as with most things systemd, it never stops there. It’s pretty easy to see where this is going.

              1. 3

                As someone a little out of the whole systemd loop. Can you explain where this may be going?