kdbus in the kernel

steveL · Posted: Mon May 04, 2015 1:16 pm Post subject:

You want this topic, FreeAsInFreedom, for the "political and money factors."

Bear in mind RedHat "gave" stock (and/or options) to quite a few core Linux developers after their IPO in the late 1990s.

Not sure on exact details, never bothered to look it up.

Shamus397 · Apprentice Joined: 03 Apr 2005 Posts: 218 Location: Ur-th

Getting back on topic (ahem), this made it's way into the kdbus discussion, though surprisingly nobody from the kdbus camp wanted to jump in to 'refute' it:

depontius · Advocate Joined: 05 May 2004 Posts: 3526

Title : "On the Importance of Bike Shedding"

For the time being, kdbus has disappeared from LKML,as far as I can tell. The silence is deafening. I'm betting that in a few months it's going to reappear with the absolute minimum of changes, basically answering Linus' worst criticisms in the least intrusive way possible. I know Linus objected to selectable endianism, and there were two other items that I don't remember at the moment. I think the fix will involve those two other things, and selectable endianism will be papered over, but not really removed.

I've spent over three decades in corporate America, and this looks like a standard pattern. A common corporate way to craft a new standard is to take whatever they've got on hand, bless it, and call it a standard. Frequently there will be some attempts at documentation that make it look "designed", as opposed to the years of happenstance, bug fixes, and enhancements that it really is. But if you peel away the covers you won't find architecture, you'll find "stuff".

Many things on the internet today were done with bikeshedding - people discussing, proposing, testing preliminary implementations, and especially important - throwing away bad stuff. Corporations seldom throw away anything - they fix it to the point where it can meet (often amended / reduced) requirements, and ship it. For all the criticism bikeshedding is often given, it can be a valuable process for producing some good standards.

But kdbus looks more like the standard corporate model. Someone had an idea, threw something together, and got it working. There appears to have been no introspection (in spite of the "introspection" feature) or willingness to toss a prototype and start over.

Along this line, one of my favorite stories was "xcb". They wanted to produce a set of native C bindings for X, instead of using Xlib. They did so, and found out that it was small and fast. Next they implemented Xlib using xcb, and discovered that it was both smaller and faster than the original Xlib. Unfortunately by the time xcb was really maturing people were starting to move past xlib into other solutions to the same problems.

I suspect that someone could re-examine dbus and put a compatible implementation on a better infrastructure, possibly using some new (not kdbus) kernel feature, possibly only using only existing kernel features, and solve all of the performance and security issues of dbus today. But I doubt that's going to happen, especially not by the dbus developers. It would take The Right Stuff to do what is needed.
_________________
.sigs waste space and bandwidth

NeddySeagoon · Posted: Tue May 12, 2015 6:49 pm Post subject:

depontius,

You must be nearly as old and cynical as me.

Your post reminds of a few quotes ...

depontius · Advocate Joined: 05 May 2004 Posts: 3526

NeddySeagoon · Posted: Wed May 13, 2015 7:14 pm Post subject:

Anon-E-moose · Posted: Fri May 15, 2015 10:03 am Post subject:

Sure been quiet on the mailing list (lkml) this week.

kdbusT didn't make it for the 4.1 kernel either. :wink:

_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland

depontius · Advocate Joined: 05 May 2004 Posts: 3526

Makes me more than a little afraid. I seriously doubt that they are re-evaluating the dbus architecture, and figuring out how to do the job properly. I'm sure that they're doing the absolute minimum and hoping that they can make it through next time.

I also have this ugly feeling that they're preparing some sort of Plan-B to get kdbus shoved into the kernel, no matter how many dead bodies it goes over.
_________________
.sigs waste space and bandwidth

NeddySeagoon · Posted: Fri May 15, 2015 6:04 pm Post subject:

Red Hat could fork the kernel if they really really wanted to.
kdbus is just another Red Hat patch.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

mv · Watchman Joined: 20 Apr 2005 Posts: 6780

NeddySeagoon · Posted: Fri May 15, 2015 6:42 pm Post subject:

mv,

With most distros becoming Red Hat clones by stealth is one thing.
When all the binary distros are running a Red Hat kernel its rather blatent.

That sort of pressure is a double edged sword.
Some binary distros may revert to sanity, even if it means dropping Gnome.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

depontius · Advocate Joined: 05 May 2004 Posts: 3526

I expect that in the coming weeks LKML will become extremely interesting - the pressure will become UGLY.

Yes, RedHat could fork the kernel. I don't expect that, I expect them to try to control it.
_________________
.sigs waste space and bandwidth

Anon-E-moose · Posted: Fri May 15, 2015 7:27 pm Post subject:

From what I have heard, RH already has kdbus as a patch against the kernel.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland

depontius · Advocate Joined: 05 May 2004 Posts: 3526

ulenrich · Veteran Joined: 10 Oct 2010 Posts: 1483

My gosh, every Redhat Linux had an ongoing forking of the kernel. Pretty much to the extent it had that much features you couldnt guess the Linux main version, if you didn't know the number nor the release date.
More than the red hats of the US military it is the application developers of the german car industrie who want the simplicity of dbus with a performance Kdbus can deliver. I must admit the evil germans pushed kdbus ...

Why dbus? It is complexity hidden behind curtains. The only question waiting in the long run: Was the dbus concept just too simple? If, then out of a sudden, now behind the curtains: "Who let the dogs out!" And complexity of this now seemingly simple minded dbus blows up again for developers. The kernel developers proposal of splitting the kdbus into more general layers will have its benefit then: To catch the wild dogs they will be able to quickly provide the next frontend for the next purpose IPC: Ldbus
For sure we will see such next letter new implementation ...

ct85711 · Veteran Joined: 27 Sep 2005 Posts: 1791

The part I find funny, is that they keep mentioning that they do not want to break compatibility with older versions. So they are not wanting to redo the old dbus because they would end up breaking backwards compatibility doing so, same with kdbus supporting the old dbus routine. Since when has the fear of breaking backwards compatibility ever stopped progress. All they have to do, like normal convention, is bump the version to the next major version, and continue on. All they need to do then is make a note at beginning of the documentation, that the new major version is not compatible to the old version and maybe add some simple wrapper functions for transitioning. Half the time, this isn't a concern for RH to begin with since they don't support old versions to worry about.

mv · Watchman Joined: 20 Apr 2005 Posts: 6780

Anon-E-moose · Posted: Sun May 17, 2015 9:16 am Post subject:

The whole "don't break compatibility" is bogus, a red herring.

It's easy to rewrite the whole "guts" of (k)dbus to be more effecient and or faster and leave the interface the same.

They are not wanting to rewrite the guts, despite being given great hints by the kernel devs and others.
I don't know it their resistance to taking others advice is a perverted form of NIH
or if there is some landmines hidden in the the twisted code (that no one has been able to follow through properly yet) and they really want to be part of (k)dbus.

Do I trust the good intentions of RH, LP, cabal et al, etc? I say no, they haven't earned the right to my trust.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland

mv · Watchman Joined: 20 Apr 2005 Posts: 6780

tld · Veteran Joined: 09 Dec 2003 Posts: 1850

GFCCAE6xF · Apprentice Joined: 06 Aug 2012 Posts: 295

Naib · Posted: Sun May 17, 2015 5:28 pm Post subject:

tld · Veteran Joined: 09 Dec 2003 Posts: 1850

NeddySeagoon · Posted: Sun May 17, 2015 6:13 pm Post subject:

tld,

but its no longer an init system. Its a kernel wrapper.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

krinn · Watchman Joined: 02 May 2003 Posts: 7470

do anyone think we're close to have a new challenger for the "software fiasco of the year" with kdbus?

What will be interesting is what redhat will do, sure they can have a patch kernel for themselves, calling it a fork or not, but it's personal use. Now if systemd depend on that patch (so systemd need a kernel with kdbus patch), that would force anyone to use a kernel with the patch (so a non vanilla kernel anymore), and write in stone redhat has fork the kernel.
And how distro will look at this: getting deeper redhat dependent or finally back to sanity and dropping systemd and all the shit.