4 ms·

> Incidentally, this might be the original reason for kdbus... Yeah, especially given that its stated reason (Moving into the kernel gives us a 2x speedup over

> Incidentally, this might be the original reason for kdbus... Yeah, especially given that its stated reason (Moving into the kernel gives us a 2x speedup over userspace dbus! Dbus is slow and we NEEED the speedup!) is mooted by the 10x speedup that cleaning up the userspace dbus libraries has achieved. [0] Having said that, in the systemd-devel post Poettering says that they're working on... > ...improving this in two ways: even if it still brings down the system, at least allow logind to handle this case nicely, so that you get a sane getty. [The other way is to push dbus into the kernel.] Systemd is a sprawling project, so I could see why it has taken more than two-and-a-half years to fix a local DOS caused by the perfectly normal method of responding to a DBUS upgrade. ;) [0] Fun fact: Those cleaned up libraries were supposed to be released after kdbus was merged into the kernel in 4.1. The Systemd Cabal was so disappointed that they had to ship the performant userspace dbus libs before the dbus daemon got pushed into kernelspace.

tmd83 11y ago
I am by no means knowledgable in the relevant domain yet this is scary at so many levels. The team that is taking charge of so many critical infrastructure not doing a minimal level of fact finding before pushing for a new kernel module for RPC is a bit obscene. I may have read things that are biased but I have a feeling it is a useful project and it does a lot of thing elegantly or right. But the project acts like it is the center of the universe and all should act to meet its needs. I have seen such project/modules at work, they usually makes everyone happy to start with and down the road when they finally get stuck and I am forced to consult we are already long way down the slope.
- intelfx 11y ago
  Goddamn, guys, stop repeating the same absurd. kdbus is NOT ONLY about performance. It's about the lifetimes, the availiability in the early userspace, the new marshalling format, the new user bus concept, and so on, and so forth. It's about separating the transport (in the kernel) and the policy (in the userspace). Most of these points can be achieved without putting the transport in the kernel, but some can not.
  - tmd83 11y ago
    Yeah right. No wonder I see people adding all sorts of adjective to the systemd proponent. I don't usually go hunting for sources and I only had Linus's comment about kdbus and performance. So I went to look for pottering's own word and here is a verbatime quote from the abstract of his presentation on kdbus D-Bus is a powerful design. However, being mostly a userspace solution its latency and throughput are not ideal. A full transaction consisting of method call and method reply requires 10 (!) copy operations for the messages passed. It is only useful for transfer of control messages, and not capable of streaming larger amounts of data. So yeah he tried to sell performance as the big thing for his version of dbus IPC. I'm guessing he (and group) spent more time with dbus than linus and failed to find the actual cause of the performance issue or tried to hide it give more credence to kdbus. In both cases it makes it that much harder to trust their reasoning and conclusions. I never said kdbus is ONLY about performance. But from what I'm reading they are not performance people but they think they are. The most dangerous people are those who don't know their own limitation or weakness. And your comment simply emphasise the practice of listening whats being said. So yeah given that I don't know dbus or ipc I have to trust your logic and you only make it hard to do so.
    - digi_owl 11y ago
      Seems the quote gets turned into a single long line in Firefox, and subsequently making the page extra wide...
      - simoncion 11y ago
        Strange. The quote is properly contained over here. FF 40.0.3 on 32-bit Linux.
  - simoncion 11y ago
    If you haven't, you should go back and read all of the LKML discussion surrounding the request to merge kdbus into Linux 4.1. Perhaps I misunderstood something, but I got the distinct impression that several of the folks reviewing the code were concerned that kdbus pushes too much policy into the kernel. LWN article: https://lwn.net/Articles/641275/ https://lwn.net/Articles/641275/ LKML thread: http://thread.gmane.org/gmane.linux.kernel/1930358 http://thread.gmane.org/gmane.linux.kernel/1930358 > It's about the lifetimes, the availiability in the early userspace... Starting dbus in your initrd [0] makes it available to the system from before the first second your service start machinery is started. If you want dbus available to userspace in your initrd, make starting dbus the first thing you do after you load your initrd. Is there some particular reason why this doesn't meet the lifetime and availability requirements? [0] Remember that the initrd is responsible for things like decrypting the rootfs. When you're in the initrd, your real system is often not even remotely ready to run.

tmd83 11y ago

I am by no means knowledgable in the relevant domain yet this is scary at so many levels. The team that is taking charge of so many critical infrastructure not doing a minimal level of fact finding before pushing for a new kernel module for RPC is a bit obscene. I may have read things that are biased but I have a feeling it is a useful project and it does a lot of thing elegantly or right. But the project acts like it is the center of the universe and all should act to meet its needs. I have seen such project/modules at work, they usually makes everyone happy to start with and down the road when they finally get stuck and I am forced to consult we are already long way down the slope.

intelfx 11y ago
Goddamn, guys, stop repeating the same absurd. kdbus is NOT ONLY about performance. It's about the lifetimes, the availiability in the early userspace, the new marshalling format, the new user bus concept, and so on, and so forth. It's about separating the transport (in the kernel) and the policy (in the userspace). Most of these points can be achieved without putting the transport in the kernel, but some can not.
- tmd83 11y ago
  Yeah right. No wonder I see people adding all sorts of adjective to the systemd proponent. I don't usually go hunting for sources and I only had Linus's comment about kdbus and performance. So I went to look for pottering's own word and here is a verbatime quote from the abstract of his presentation on kdbus D-Bus is a powerful design. However, being mostly a userspace solution its latency and throughput are not ideal. A full transaction consisting of method call and method reply requires 10 (!) copy operations for the messages passed. It is only useful for transfer of control messages, and not capable of streaming larger amounts of data. So yeah he tried to sell performance as the big thing for his version of dbus IPC. I'm guessing he (and group) spent more time with dbus than linus and failed to find the actual cause of the performance issue or tried to hide it give more credence to kdbus. In both cases it makes it that much harder to trust their reasoning and conclusions. I never said kdbus is ONLY about performance. But from what I'm reading they are not performance people but they think they are. The most dangerous people are those who don't know their own limitation or weakness. And your comment simply emphasise the practice of listening whats being said. So yeah given that I don't know dbus or ipc I have to trust your logic and you only make it hard to do so.
  - digi_owl 11y ago
    Seems the quote gets turned into a single long line in Firefox, and subsequently making the page extra wide...
    - simoncion 11y ago
      Strange. The quote is properly contained over here. FF 40.0.3 on 32-bit Linux.
- simoncion 11y ago
  If you haven't, you should go back and read all of the LKML discussion surrounding the request to merge kdbus into Linux 4.1. Perhaps I misunderstood something, but I got the distinct impression that several of the folks reviewing the code were concerned that kdbus pushes too much policy into the kernel. LWN article: https://lwn.net/Articles/641275/ https://lwn.net/Articles/641275/ LKML thread: http://thread.gmane.org/gmane.linux.kernel/1930358 http://thread.gmane.org/gmane.linux.kernel/1930358 > It's about the lifetimes, the availiability in the early userspace... Starting dbus in your initrd [0] makes it available to the system from before the first second your service start machinery is started. If you want dbus available to userspace in your initrd, make starting dbus the first thing you do after you load your initrd. Is there some particular reason why this doesn't meet the lifetime and availability requirements? [0] Remember that the initrd is responsible for things like decrypting the rootfs. When you're in the initrd, your real system is often not even remotely ready to run.