:: Re: [DNG] We Must be Prepared ....
Inizio della pagina
Delete this message
Reply to this message
Autore: James Powell
Data:  
To: Jude Nelson, Richard
CC: dng@lists.dyne.org
Oggetto: Re: [DNG] We Must be Prepared ....
The problem is, kdbus isn't just an IPC, it's proprietary to systemd, and is the only software capable of utilizing it.

Greg Hartman as the lead-takeover for Linus? Hell no. He'd give it to Lennart and Kay without batting an eye, and then shut out every developer save their own.

Dare I say it, but Peter Griffin or Homer Simpson would be better choices...

If Hartman takes over, the kernel will have to be forked. His track record of kissing Lennart's ass is too obvious. No no and no.

Sent from my Windows Phone
________________________________
From: Jude Nelson<mailto:judecn@gmail.com>
Sent: ‎6/‎18/‎2015 9:20 AM
To: Richard<mailto:richard.holt@gmail.com>
Cc: dng@???<mailto:dng@lists.dyne.org>
Subject: Re: [DNG] We Must be Prepared ....

I'm not worried. Linus won't accept kdbus until he thinks it's in a
position where it will be stable and easily supported for the foreseeable
future. Watching kdbus get refactored a few times over this past year, I'd
wager a guess that they're going to end up keeping as much of dbus in
userspace as possible, and only add the parts that absolutely must run in
kernel space to the kernel (as kdbus). Thus far, this has been limited to
the memfd API, which is needed for zero-copy memory transfers. They'll
probably also end up adding a specialized kdbusfs (akin to devpts) that
offers namespaced and permissioned access to dbus endpoints, represented as
a hierarchy of character device files.

Remember, kdbus isn't dbus, anymore than a UNIX domain socket is dbus. The
reason they're working on kdbus at all is because they have discovered that
it's costly to pipe a lot of data between dbus endpoints, and it's hard to
control capabilities, visibility, and access to them (since there are
usecases where endpoints may not trust each other). Arguably, these
problems can be addressed by using a combination of existing IPC
mechanisms, but the argument that Greg KH and company put forth over and
over again is that there's too much legacy code using dbus at this point
(namely, from the IVI community and desktop communities) that we can't just
tell them to refactor everything. It might be true--I don't know how big
the IVI codebases are, for example. However, I don't really sympathize
with the desktop communities--they built dbus to their specifications from
their experiences with DCOP and Bonobo, and still managed to get it wrong.

My $0.02.
-Jude
_______________________________________________
Dng mailing list
Dng@???
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng