[lkml]   [2015]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PULL] kdbus for 4.1-rc1
> 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

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

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


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.


 \ /
  Last update: 2015-04-15 16:41    [W:0.175 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site