Re: [GIT PULL] kdbus for 4.1-rc1

[One Thousand Gnomes]

> 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.

And if you look at those systems btw many of them have a very compact,
very clean very simple message passing interface,often in the hundreds
not tens of thousands of lines of code.

> 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).

We put the IP stack in the kernel not the shopping cart. A good shopping
cart of course only has state on the client.

> 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).

I'm not convinced the naming data belongs in kernel beyond the simplest
of "node 147". I'd offer a sort of proof by armwaving of this that if you
have


/dev/dbus/014   /dev/dbus/027 etc

you can add a symlink to /dev/dbus/014 of

/dev/dbus-by-name/gnome-wombat-grooming-daemon

or whatever

and we do that today for every other naming database and static
allocation we've spent the past 15 years evicting from the kernel.

That state isn't then held in a daemon that can crash nor is it invisible
to debuggers, user tools and admins.

Alan
--
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/