kdbus in the kernel

[Naib]

Any IPC can be used to circumvent the GLP and yes that includes files and TIPC. If the author of a library decides to expose its entire API to an IPC (instead of requiring linkage -> gpl inclusion) then well... more fool them. HOWEVER something still needs facilitate the link (a library doesn't run without some application using it) so you need clear intentions to bypass the GPL via an IPC

1) some gpl library/program must expose its API to an IPC
2) something must launch the library.

So why is the IPC the boogyman here when it is the author of the glp'ed library that facilitated it? its like blaming the gun for someone shooting up a school - non sequitur. Would you blame Ext4 for facilitating in bypassing the GPL (and yes I have done something nasty with files as an interprocess comms to produce a crude co-processor between matlab and EFFE [FEA application] as I could take credit for EFFE watching for a certain file to auto exec and a simple matlab script was written to watch for a suitable output file...

Linking (and thus being wrapped in the gpl) will always be faster due to the shared memory
KDBus/TIPC in theory would be the next fastest
DBus
Sockets
Files


If there is a conspiracy to bypass the GPl via an IPC ( as 1st popped up here: http://slashdot.org/comments.pl?sid=5735323&cid=47959449) it for starters wouldn't be the first (gpl3 was created to close a tivo loophole iirc)


Sysd are the most vocal with regards to needing dbus, their aim is to perpetuate sysd and if you notice they created sd-bus "a fun api to provide inter process communication" which will use dbus or kdbus. While sysd has made it clear they would target ONLY linux, sdbus has been released cross-platform (inc windows).
At a guess I would think GNOME and its apps would jump onto sdbus ASAP as it would "simplify their applications dbus interface" and they would magically get a performance boost if kdbus is present - the fact KDBUS isn't that efficient doesn't change the fact it is a boost over userland AND it could, if further optimised give a big boost.

One thing I would say around KDBUS is if an in-kernel IPC is required or is deemed the next evolution, there is one thing to concider with KDBUS over others: https://xkcd.com/927/
Now I am not saying KDBUS is great or will be great if/when they sort it out

What's more realistic is RH/Systemd intention to wrap the kernel completely and thus no application needs to interface with the kernel BUT must go via systemd. Systemd includes an EFI bootloader, systemd is the handover from kernel to userspace for init... more and more of linux is being encapsulated in systemd which provides a level of abstraction. So rather than userland interfacing with the kernel, they would all interface via systemd
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;

[augustin]

Thanks, Naib. Your comment helps me understand a bit better the whole debate, although, I am sure, I still have much more to learn.

[ulenrich]

[mrbassie]

[ulenrich]

[Naib]

[mv]

[ulenrich]

[Naib]

I know there wasn't (so that is at least an improvement upon hte previous two or three...). Just because there isn't a new pull request doesn't magically change history and scrub the fact that there were previous pull requests AND at least one API change
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;

[mrbassie]

[ulenrich]

[gwr]

[depontius]

I like this little tidbit, which draws parallels between kdbus and the in-and-out devfs: https://lkml.org/lkml/2015/6/25/42

On another level, there's something else going on here, and I don't think it's generally recognized. L.P. has forced the issue by pushing the kdbus-first requirement out to the distributions with systemd. Linus is clearly feeling the pressure, knowing that a kernel change may prevent systems from booting. He hasn't phrased it as pressure, but he clearly recognizes that the problem exists, and appears to be getting ready to act on that perceived problem.

In other words, systemd has taken over some portion of the kernel decision process and control.

There will be two further litmus tests:
1 - The next time they want to juggle the kdbus API in an incompatible way.
2 - When they reach elsewhere in the kernel and make kdbus the way to signal udev events. ("Gentoo, you have been warned!" If not exact, that's a near-exact quote.)

There are two other stated directions by the systemd team:
1 - Systemd writes to Linux, and everyone else writes to systemd. In other words, only one Linux user - systemd, the rest of us become systemd users.
2 - The kernel moves in lockstep with system.

At the risk of courting Godwin, there have been other times in history when you don't even have to read between the lines. There have been times when intentions have been stated out in the open, and nobody really believed it. Then when those intentions are acted on, people seem surprised that that's happening.
_________________
.sigs waste space and bandwidth

[steveL]

[steveL]

[steveL]

[ulenrich]

[gwr]

[krinn]

[steveL]

[Shamus397]

Well, lookie here, this just landed in the lkml.

[steveL]

Nice review, and clearly correct, from the reply.

[gwr]

[steveL]

[Naib]

Round n+1.

http://lkml.iu.edu/hypermail/linux/kernel/1507.0/02970.html
_________________
#define HelloWorld int
#define Int main()
#define Return printf
#define Print return
#include <stdio>
HelloWorld Int {
Return("Hello, world!\n");
Print 0;