Re: Issues with capability bits and meta-data in kdbus

[Havoc Pennington]

On Wed, Apr 22, 2015 at 7:40 AM, Austin S Hemmelgarn
<ahferroin7@xxxxxxxxx> wrote:
> Except, IIRC, that was one of the stated design goals in the original patch
> set.  I'm pretty sure that i remember a rather verbose exposition that
> pretty much could be summarized as "Linux has no general purpose IPC in the
> kernel, this fixes that"
>

This is probably just debating definitions and technicalities, but
what I'd say is that dbus is pretty universally applicable *within*
the case of connecting apps and services on the local machine. That's
what it's for. Right now it probably works for I don't know, 85-90% of
that, with kdbus trying to take it closer to 100% by removing
performance concerns and early boot concerns that currently rule out
certain uses.

If we say it isn't "general purpose" we could mean more than one thing -

 - it's a complete system / batteries-included, with a defined
protocol, vs. a "make your own protocol" kit
 - it isn't especially appropriate as a cross-machine protocol,
whether you mean within a cluster or across the internet
 - it isn't portable in a very useful way (it kind of runs on
windows/mac but isn't the native way of doing things there)

On the other hand, it is "general purpose" in the sense that so many
apps and services are using it for so many purposes already (i.e. it
isn't tied to a particular kind of app or service).

I just opened d-feet on my workstation which is default-ish Fedora 21,
I have ~35 well-known names available on the system bus, and ~100 (got
tired of counting) on the session bus. These are all kinds of
different apps and services.

d-feet incidentally is a good way to explore current usage of dbus -
you can list names, list objects within names, list methods/properties
on objects, and even call methods from d-feet. (There are command line
alternatives too like `gdbus`.)

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