But kdbus hasn't proven itself in regular usage, except only by systemd. Where are the figures for kdbus with other D-Bus using software and services? I don't believe there are any, and if kdbus has been touted so much to be the perfect successor to D-Bus, why aren't other packages making headway to make their packages kdbus compliant to test the viability of kdbus?

The one benefit we could get out of this are distributions waking up and saying no to including non-mainstream kernel code, and berating Lennart for wanting or requiring non-vanilla code. Most distributions only have traditionally included patches to fix known kernel issues, but anything else has been classed as forbidden.

If anything Lennart may have put the metaphorical knife to the throat of systemd without realizing it.

Sent from my Windows Phone
________________________________
From: Didier Kryn<mailto:kryn@in2p3.fr>
Sent: ‎6/‎20/‎2015 2:49 AM
To: dng@???<mailto:dng@lists.dyne.org>
Subject: Re: [DNG] We Must be Prepared ....

Le 20/06/2015 11:06, James Powell a écrit :
> Then this without a doubt is clear evidence that kdbus is in fact a
> systemd proprietary IPC. Has anyone heard of any software otherwise
> that will use kdbus at all, even in the least?
>
> Lennart is desperate to get kdbus in, but is making a critical error
> in judgment with this. No distribution has ever added software to the
> kernel that has been 3rd party via patch, or has limited function,
> other than Gentoo that maintains a patch for OpenRC. ZFSOnLinux has
> never been allowed, neither has Reiser4, or any other non-vanilla
> code, nor any code from Linux-next.
>
> No package developer in their right mind would do such a lascivious
> addition to the kernel, nor would dare to.
>

     OK, kdbus is required eagerly by systemd developpers. So what?
Don't you think normal that such an important and critical thread of
software development finds that it misses some service that only the
kernel can provide efficiently? Isn't it normal that the kernel team
examines seriously the request and eventualy provides that service?

     This kdbus feature, if we don't want to use it, we don't use it. It
may even be optional and you can disable it when compiling the kernel if
the mere availability of this system-call irritates you. It may also
happen that other applications than systemd make use of kdbus for their
own needs.

     From a bad thing (systemd) could hapen good things. For example,
systemd-infected distros are now forced to include both sysvinit and
systemd init files if they pretend to continue sysvinit support. They
may consider some day doing what we are discussing in another thread:
providing init packages for every daemon. Or devising a generic
description of daemon dependencies and invocation method, which would
allow to use universal start/stop/reload scripts.

     Didier

_______________________________________________
Dng mailing list
Dng@???
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng