Kernel prepatch 4.1-rc1

Posted Apr 27, 2015 14:42 UTC (Mon) by ebiederm (subscriber, #35028)
In reply to: Kernel prepatch 4.1-rc1 by Thue
Parent article: Kernel prepatch 4.1-rc1

For kdbus to productively move forward people need to stop and really listen to the concerns other people have, and not attempt to make a list of boo-boos to be fixed.

Even if you just concentrate on the boo-boos many of the review efforts of kdbus stopped short because of issues that were seen. There is no reason to presume that deeper looks at kbus will not uncover other unaticipated concerns.

All that is safe to say at this point is the conversation is not complete.

Kernel prepatch 4.1-rc1

Posted Apr 27, 2015 14:57 UTC (Mon) by Thue (guest, #14277) [Link] (9 responses)

> really listen to the concerns other people have

Well, I tried to list the concern I am aware of. You seem to think my list is incomplete, so please go ahead and elaborate.

> and not attempt to make a list of boo-boos to be fixed.

So making a list of concrete obvious problems to be fixed is bad thing?

> There is no reason to presume that deeper looks at kbus will not uncover other unaticipated concerns.

IIRC then kdbus has been under development for 2 years now. Of course there could be other issues not found yet, but that is the case with all code in the kernel. People have had plenty of time and opportunity to raise issues already.

Kernel prepatch 4.1-rc1

Posted Apr 28, 2015 13:44 UTC (Tue) by d9 (guest, #102181) [Link]

> please go ahead and elaborate

You can start here:

http://article.gmane.org/gmane.linux.kernel/1939166
http://article.gmane.org/gmane.linux.kernel/1939022

> kdbus has been under development for 2 years now

It is unfortunate that a lot of time and money was spent on it, but that is a silly reason to force its adoption into the kernel, especially when the main justification for its existence (improving DBus performance) appears to be flawed.

"Premature optimization is the root of all evil." Some people learn it the hard way.

Kernel prepatch 4.1-rc1

Posted Apr 28, 2015 14:04 UTC (Tue) by d9 (guest, #102181) [Link] (7 responses)

(sorry for double posting)

Another problem that I have with kdbus is that it is middleware. From what I have seen over the last couple of decades, middleware solutions tend to have a short lifespan. There is always a "new" thing, which is so much "better" than the previous one. But eventually they end up hated and abandoned for various reasons (be it performance, security, reliability, change in requirements -- e.g. connecting applications running on multiple hosts instead of a single host, which DBus/kdbus does not address, and probably never will if it morhps into kdbus).

Why add kdbus into the kernel if 10 years from now nobody will use it?

This reminds me of the database products which around 2000 spent a few years trying to integrate XML into SQL databases. It never really worked well, and by the time they were done, XML had already faded off (it was replaced by other methods of serializing data) and people also shifted interest to distributed databases.

Kernel prepatch 4.1-rc1

Posted Apr 28, 2015 14:38 UTC (Tue) by pizza (subscriber, #46) [Link] (4 responses)

> Why add kdbus into the kernel if 10 years from now nobody will use it?

Then it can be marked as deprecated and eventually removed...

Kernel prepatch 4.1-rc1

Posted Apr 28, 2015 15:55 UTC (Tue) by juhl (guest, #33245) [Link] (3 responses)

Once it is in the kernel it becomes ABI that is more-or-less impossible to remove without breaking userspace.
Yes, you can deprecate it and discourage its use but to actually remove could easily prove impossible or a project with a timespan of 10-20 years - and it still has to be maintained during that time.
So the "we can just deprecate and remove it" argument really doesn't hold. It needs to be really solid before getring merged or we'll have a lot of future pain on our hands.

Kernel prepatch 4.1-rc1

Posted Apr 28, 2015 16:15 UTC (Tue) by nye (subscriber, #51576) [Link] (2 responses)

>Once it is in the kernel it becomes ABI that is more-or-less impossible to remove without breaking userspace.

That doesn't really apply here, since in this case "remove it" really means "move it back into userspace where it is right now".

Kernel prepatch 4.1-rc1

Posted Apr 28, 2015 18:33 UTC (Tue) by juhl (guest, #33245) [Link] (1 responses)

Except you'd still have syscalls, ioctls or other gunk lying around. Once the kernel exposes an interface that userspace can invoke that interface has to stay in place and be functional - even if 99% of everyone move to the userspace interface.

Kernel prepatch 4.1-rc1

Posted Apr 29, 2015 12:00 UTC (Wed) by nye (subscriber, #51576) [Link]

Oh I see. I was thinking in terms of of consumers of an API that don't care about the implementation details beyond "it does what I need, as quickly as I need", in the same way that when I link against glibc I don't care whether or not it has to do some song and dance to get some function to work on some particular kernel (does that happen? I've never had to care).
But that was rather short-sighted - some software will of course end up calling the kernel's own interfaces directly you would at least need an ABI shim to stay around forever.

Kernel prepatch 4.1-rc1

Posted Apr 28, 2015 15:20 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

It is also useful to point out that dbus has been around for 10+ years already and is seeing more usage, not less, so it's probably going to be around for 10+ years more, it didn't just fall off the turnip truck yesterday and the people who develop it haven't either.

Kernel prepatch 4.1-rc1

Posted Apr 28, 2015 17:08 UTC (Tue) by d9 (guest, #102181) [Link]

That doesn't invalidate the comparison. XML was designed around 1996 and it was essentially a trimmed down version of SGML, which appeared in the late 80's (in turn derived from GML, created in the 60s). It's much older than DBus.

If DBus appears to be gaining more traction, it's great. I hope whatever solution is chosen is flexible enough to survive a long life.