KDBUS Is Indeed Going Back To The Drawing Board

[phoronix]

Phoronix: KDBUS Is Indeed Going Back To The Drawing Board

It doesn't look like KDBUS will be ready for merging into the mainline Linux kernel anytime soon...

http://www.phoronix.com/scan.php?page=news_item&px=KDBUS-Back-To-Design

[duby229]

Well, I can't say I know what's best, but if kdbus ever gets upstreamed then it will be kernel code, shouldn't it be developed according to the kernel's policies?

[Scias]

In before the Plan9/Plumber zealots.

On topic, it's quite a good news that they go back to the drawing board to make it less D-Bus'y. That means, contrarly to what the anti-systemd crowd likes to think, that they listen to the constructive critics and aren't going to shove it down everyone's throats.

[yoshi314]

In before the Plan9/Plumber zealots.

On topic, it's quite a good news that they go back to the drawing board to make it less D-Bus'y. That means, contrarly to what the anti-systemd crowd likes to think, that they listen to the constructive critics and aren't going to shove it down everyone's throats.

this all happened after they tried shoving it down people's throats.

imagine what would happen if kdbus went into the kernel and then someone said "you know, this is a bad design. let's rewriite it"

[jrch2k8]

In before the Plan9/Plumber zealots.

On topic, it's quite a good news that they go back to the drawing board to make it less D-Bus'y. That means, contrarly to what the anti-systemd crowd likes to think, that they listen to the constructive critics and aren't going to shove it down everyone's throats.

Well greg is a real badass kernel developer with years of experience, so he defend his code and fix suggestion, more defending and some lkml heat, decide to release code in the wild and see real use cases, crap unexpected designs flaw, back to board. Basically every Wednesday for any kernel developer, seriously this should not even be newsworthy but since its related to systemd every troll active in the closest 100 galaxies is following it line by line trying to find something to bash to systemd. Lol some people don't even realise there are kernel code that took years and hundreds of revisions to reach a spot in staging.

Back into topic i agree is nice greg and the team got some real usage data and decided to improve the original design and strip some fat out of dbus, i mean i like dbus overall but many features were written back in the day when still was "better than nothing" but for today standards most are either unneeded, non sensical, too slow, etc. Sure this fat trimming will break user space dbus1 but they can always call it dbus2 and let unmaintained apps using the good old dbus1(this probably will be the case for the tinfoil hat crowd too) while the rest of the ecosystem adapts to dbus2/KDBUS properly specially since this days most of bus is abstracted by toolkits(only crazy people use libdbus1 directly anyway)

[Veto]

Well greg is a real badass kernel developer with years of experience, ...

This! If I ever have the opportunity to meet Greg in person, I will certainly buy him a beer.

[Ericg]

this all happened after they tried shoving it down people's throats.

imagine what would happen if kdbus went into the kernel and then someone said "you know, this is a bad design. let's rewriite it"

If you read the mailing list posts, both the kernel posts and the posts to fedora's -devel list, the reason it got pulled is because they realized it was a bad design AFTER getting the additional exposure in downstream distros like Fedora's rawhide kernel. They didn't "shove it down peoples throats", kdbus got added to rawhide FOR additional testing, and they requested that distros start experimenting with it FOR additional testing and to make sure that things were staying compatible. Things worked out exactly how they should have-- they called for testing, tests came in, they realized problem points, and they went to address them. Except in this case "addressing them" meant a refactor / rewrite.

[justmy2cents]

Well greg is a real badass kernel developer with years of experience

why do i always think of "Meat bicycle" whenever i see word badass?

[Scias]

Well, I can't say I know what's best, but if kdbus ever gets upstreamed then it will be kernel code, shouldn't it be developed according to the kernel's policies?

What policy ? It's not because they are making a kernel module that their development must take place in the kernel mailing list...

this all happened after they tried shoving it down people's throats.

If that was the case then systemd would default to kdbus, which isn't the case. kdbus was an optional boot flag on Fedora that's it.

[cb88]

(only crazy people use libdbus1 directly anyway)

Therein lies the problem... if your library is such crap that no one uses it directly, and just writes wrappers for it to pretty it up, when it was designed to be used directly, then your code is garbage. So, What you end up with is a bloaty library due to it being hacked up to improve it's flaws over time as well sa even more bloaty usability abstraction on top. All of this violates KISS principles that EVERYONE should follow. For a long time the linux kernel had a complex "smart" scheduler but recently it has been found that it hit the cache so hard that a simpler one was significantly faster in most cases especially the ones where they wanted the old one to be faster (CFQ scheduler is an example of this but... there are others as well) If you google back it looks like this is deja vu as around 1998 there was a scheduler rewrite that had similar findings.