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

  • From: Marty <martyb@xxxxxxxxxxxxx>
  • To: modular-debian@xxxxxxxxxxxxx
  • Date: Sat, 06 Dec 2014 10:03:39 -0500

Hi Jude,

On 12/06/2014 03:36 AM, Jude Nelson wrote:
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.

As I mentioned in my other message, this looks like what Plan 9 is
doing. I think this is a natural solution to the problem, and history
bears that out.

  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.

How does this compare to tmpfs?

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

As I mentioned, this appears to be what Plan 9 is doing with the
"everything is a file" paradigm. It looks very much like a step in the
right direction, but I am just learning (just in the last few weeks).

Any thoughts or feedback welcome :)

IPC touching everything in the system (and kernel through kdbus, eventually) means this is a big reorganization of userspace, maybe on
the order of what systemd is trying to do. It probably puts you in
head-to-head competition with systemd.

I think everyone is coming to grips with the scale of the problem,
but you seem ahead of the game in terms of a possible solution.

Regards,
Jude

[0]
http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt
[1] https://github.com/jcnelson/fskit
[2] https://github.com/jcnelson/runfs



On Thu, Dec 4, 2014 at 5:36 PM, Martinx - ジェームズ <thiagocmartinsc@xxxxxxxxx>
wrote:

On 4 December 2014 at 14:03, David L. Craig <dlc.usa@xxxxxxxxx> wrote:
> Can we agree dbus is to be avoided?

I'm using Linux since 1996 (Debian since Potato), never used dbus (on
servers) in my entire life.

I see no reason to start using now.

Cheers!





Other related posts: