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