[modular-debian] Re: Replace dbus with per-service filesystems (was: Re: Humor With A Message: dbus)

  • From: Steve Litt <slitt@xxxxxxxxxxxxxxxxxxx>
  • To: modular-debian@xxxxxxxxxxxxx
  • Date: Sun, 7 Dec 2014 11:28:48 -0500

On Sat, 6 Dec 2014 03:36:02 -0500
Jude Nelson <judecn@xxxxxxxxx> wrote:


> Recently, this blog post [0] got me thinking about the state of
> affairs with regards to dbus-exposed services.  Given how
> filesystem-like dbus is, why not simply design services to export a
> userspace filesystem in the first place (taking a leaf out of Plan
> 9)?  I think doing so would promote a more modular, composable
> userspace than what we have today with dbus, 

I think dbus sucks and is horribly open to abuse, and is being abused.
But that's not the end of the story, read on...


> If my understanding of dbus is correct (someone please correct me if
> I'm wrong), the key features it offers to applications include the
> following:
> * signals and methods as first-class entities
> * hierarchical organization:  processes aggregate related signals and
> methods under common prefixes; two different processes A and B have
> their own prefixes to avoid namespace collisions
> * introspection:  process A can query the signals and methods exposed
> by process B
> * RPC-like IPC semantics:  process A can invoke methods in process B
> (both synchronous and asynchronous operations are allowed)
> * 1-to-N broadcast:  process A can send a signal to one or more
> listener processes B1...BN.
> * authentication:  processes A and B only interact once they prove to
> one another that they each know a shared secret (which is shared
> out-of-band by a mutually trusted party, like a session manager or an
> ancestor process).
> * activation and lifecycle management:  process A can learn when
> process B exposes or withdraws an API

I look at the preceding list, and for the most part, they look like bad
habits to me. For the sake of debugability, I prefer that if A and B
need to communicate, they are built from the ground up to recognize
each others common API, not throw and grab info to/from some sort of
generic "we accept everything" entity. I'm a big fan of well defined

But that's not the end of the story. Read on...

> But, if this is what dbus conventionally gets used for, then I think
> the features offered by dbus could be addressed with a userspace
> filesystem as well:
> * signals and methods:  represented by files, or well-defined
> directory structures
> * hierarchical organization:  directory trees
> * introspection:  opendir(), readdir(), stat(), getxattr(),
> listxattr()
> * RPC-like semantics:  open(), read(), write(), close(); can be used
> to emulate method invocations if need be (i.e. write arguments to a
> file; read result from a file).
> * 1-to-N broadcast:  combination of select()/poll() and read() (also:
> inotify(), kqueue, etc.)
> * authentication:  process's PID, effective UID/GID, access(), path
> resolution
> * activation and lifecycle management:  mount(), umount(), mount
> namespace (/etc/mtab, /proc/mounts)

Filesystems are good. If you *simply must* have a communal
communication path, at least a filesystem is examinable. And, if you
have a function to write a snapshot out to disk, then forensic
examination is possible. Also, I have a feeling that what you describe
could be used for things that aren't as bug-attractive as the list of
dbus "benefits" you first mentioned. I hope you have ways of making
certain communications private to specific apps.

> I'm convinced that per-service filesystems encourage modularity
> better than dbus to the point that I've gone ahead and created a
> library, called fskit [1], that makes it easy to embed them into
> services.  Unlike FUSE, fskit handles all the bookkeeping required to
> maintain a POSIX-y directory hierarchy, and lets the service
> programmer define WSGI-style routes to handle I/O operations over
> sets of paths (a multi-threaded RAM filesystem can be had in about
> 200 lines of C).  It's almost ready for a stable release--it's only
> missing symlink and hard-link support at this point--but I've already
> used it to create a special RAM filesystem, called runfs [2], that
> automatically removes files once the process that created them dies
> (i.e. no more stale PID files).  I use it every day to avoid
> polluting my /tmp with files generated (but not cleaned up) by
> software I work on at $DAYJOB.

I'll help you document it.

If you make it small and tight and clean enough, it might be of value
in the init system itself.

> Before I dive off the deep end into doing something big like
> re-implementing udev, I'm looking for a sanity check.  Is what I'm
> trying to do a desirable, or even a sensible, approach towards
> encouraging a more modular debian?  

I have no idea. But I do know that using the filesystem for information
is usually a good idea. I guess your main purpose in making it an
in-memory filesystem is performance???

> To be clear, it's not that I
> dislike dbus; it's that the lack of generic interfaces between dbus
> components makes it difficult for me to avoid tightly coupling
> multiple dbus services together.  

Having a common wire conducting all interprocess communications is a
very abuseable thing, no matter how well you write it. Yours looks a
little more debuggable than dbus. Especially if you include a log.

> I think this can be avoided if
> services stuck to generic conventions for interacting with the rest
> of the system (such as the POSIX filesystem API), since then existing
> tools would not need to be designed around the services'
> otherwise-arbitrary methods and their arbitrary side-effects.  I
> think making it easy for services to expose functionality through the
> filesystem is a big step in this direction.
> Any thoughts or feedback welcome :)

You're already using it, and it's solving some of your problems.
Hopefully it has few dependencies and is easy to deploy. If this is a
free software project, I'll help you document it.

Personally, I think it can be used for other, better things than a dbus


Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

Other related posts: