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@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
