Re: [GIT PULL] kdbus for 4.1-rc1

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Wed, Apr 15, 2015 at 11:37:27AM +0100, One Thousand Gnomes wrote:
> On Wed, 15 Apr 2015 00:39:22 +0200 (CEST)
> Jiri Kosina <jkosina@suse.cz> wrote:
> 
> > On Tue, 14 Apr 2015, Greg Kroah-Hartman wrote:
> > 
> > > I don't understand.  You can not like the D-Bus model (and accordingly
> > > the X11 model), 
> > 
> > I thought that the general hatred level of the X11 "model" and the 
> > protocol lead to al the efforts to reimplement this properly ... in 
> > userspace (for example Wayland, right?).
> > 
> > I don't think anyone was ever seriously suggesting "X11 model is broken, 
> > so let's push it to kernel" ... ?
> 
> The X11 model is *nothing* to do with the dbus/kdbus model. X11 does
> properties by attaching them to windows. Those properties can be
> monitored for changes and they can be queried. Setting them is
> asynchronous, querying them is sync or with the newer event based
> libraries can be async. X11 properties are network safe, handled through
> the same X11 authority as everything else. Two apps can happily run on
> different systems sharing a display over the network and sharing and
> responding to changes in X11 properties - and it just works.
> 
> The Gnome people tried to re-invent X11 properties and embedding badly
> with CORBA, then with dbus, despite the fact the Andrew system could
> already do it really fast and cleanly even before Gnome was thought of.
> 
> There is no comparison between the elegance of X11 property setting and a
> chunk of proposed kernel code that is half the size of a tiny X server!

Hey, take that up with Havoc, he made the comparison :)

> The dbus model is also flawed in a load of other ways in user space
> because message handling in the hands of people with no concept of
> systemic performance analysis just leads to disaster. One of the big
> reasons dbus is so "slow" isn't that dbus is "slow", it's that the
> crapware on top of it makes *thousands* of dbus queries.

There's the issue of thousands of dbus queries, and then there's the
issue that making those queries takes a measurable amount of time.  We
can fix the later one, the first one, well, not so much, but we can
provide the resources for them to make a faster system if they want to.

> If you must do it in kernel why not use the Android binder - it's awful,
> broken, and dubiously secure, but at least we'd still only have one awful,
> broken dubiously secure rpc/property layer in kernel.

Binder does not match up to the dbus model at all, I've written about
this in the past, and can dig it up again if you want.  And, there is
active research in moving the binder userspace library onto the kdbus
code base, allowing the binder kernel driver to be removed one day.
That would be a good thing to have happen, but I'm not holding my
breath for it.  Using it the other way around isn't going to work.

> "It's the issue that a stateful bus is required for
> applications that is the main point I'm trying to get across."
> 
> That would be the "if dbus crashes I have to reboot" design flaw of
> Gnome and friends. The only state you need is beyond the endpoints. It's a
> message passing system. If you think message passing needs state then I'd
> take a look at the internet. State belongs in the end points.

The internet model with state in the endpoints doesn't always transfer
properly to local applications, see Havoc's email for the details about
that.

> It's telling that I can lose and recover my internet connection without
> rebooting but not my desktops internal messaging.

Yes, as those are totally different things, let's not mix the issue up
here please.

thanks,

greg k-h