Re: [GIT PULL] kdbus for 4.1-rc1

[Greg Kroah-Hartman]

On Wed, Apr 15, 2015 at 01:03:54PM +0100, One Thousand Gnomes wrote:
> > > 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 :)
> 
> And it concerns me you blindly repeat it without realising its wrong.

It's a metaphor that makes sense to me given my limited knowledge of the
x11 protocol.  If it's wrong, ok, I'm willing to learn, but I think it's
still relevant here.

> > > 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 fix the thousands of queries problem do you need kernel help at
> all.

I've worked with developers of such systems, and no, they can't fix that
problem.  They are using "legacy" applications that they have to run on
some type of operating system, and really don't want to use legacy
operating systems anymore.  Those "legacy" oses provide a system bus
that allows them to send thousands of queries just fine, but when moving
to Linux, we don't have anything other than D-Bus, so their library is
ported to use it, and they have to handle their old applications that
need/want the zillions of messages.

Then they thow the thing on a very underpowered ARM processor and
complain about boot time being so slow, but that's a different issue...

> > 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.
> 
> URL ?
> 
> (note how beautifully btw the stateless network and the URL string will
> become a reference to state)

Heh, yes, but there's very little state here:
	http://lists.freedesktop.org/archives/dbus/2015-April/016651.html

There's also a follow-on message from the current D-Bus maintainer:
	http://lists.freedesktop.org/archives/dbus/2015-April/016653.html

> > > 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.
> 
> They are *NOT* different things. They are fundamental properties of the
> underlying architecture. I worked on stateful networks and still have
> the scars. It is a fundamental property of stateful network that every
> time any key component goes castors up you lose the lot. It is a fairly
> fundamental property of stateless networks that equipment going castors
> up has no material impact on the network
> 
> The internet is built upon three fundamental breakthroughs in technology
> 
> - That stateless networks scale and can be reliable while stateful ones
>   cannot scale and cannot be fixed to do so
> 
> - That flow control is possible over a stateless network
> 
> - That efficient data routing is possible over a stateless network
> 
> Those are absolutely critical parts of any network or messaging
> implementation.

People take those stateless models and build stateful ones on top of
them, yes, it's great.  But you still need a stateful model somewhere in
order to be able to achieve many things (think a shopping cart
application).

Anyway, this is getting off-topic, there is very little "state" in the
kdbus kernel code here, other than a naming database that Havoc and
Simon explain the need for, and the normal lifecycle of kdbus "nodes"
(new, linked, active, inactive, drained, freed).

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/