On 2015-06-18 14:13, James Powell wrote:
> 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.

Even linus called him a kay sievers babysitter ...

> -------------------------
> From: Jude Nelson
> Sent: ‎6/‎18/‎2015 9:20 AM
> To: Richard
> Cc: dng@???
> 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
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

--
Stop slacking you lazy bum!