[modular-debian] Re: Replace dbus with per-service filesystems

  • From: Jude Nelson <judecn@xxxxxxxxx>
  • To: Marty <martyb@xxxxxxxxxxxxx>
  • Date: Sat, 6 Dec 2014 23:05:38 -0500

I don't think it's necessary to compete with /proc.  Instead, I hope to
complement it:  let /proc handle the generic stuff common to all processes,
and let fskit help a process export any extra information and control
interfaces via the filesystem at a user-chosen mountpoint.

I've read through the dbus spec and kdbus documentation (not really looked
close at the code for either yet), and the general feeling I get is that
dbus is trying to enable "stateful" shared libraries by allowing programs
to "dynamically link against" services.  This is advantageous in certain
circumstances because unlike shared libraries, services maintain state
across program lifecycles.  This would explain the need to add a few more
IPC primitives to the kernel--enable fast and secure calls to "dynamically
linked" service methods by getting the (mutually trusted) kernel in on it.
If anything, it looks like its trying to solve the same problem that
Solaris's "door" abstraction [0] did.

Insofar as benchmarks, I know from my own testing that FUSE isn't
particularly fast at bulk-data transfer compared to native filesystems (not
sure about how it compares against POSIX IPC abstractions or kdbus).
Fortunately, it doesn't need to be--API-like filesystems don't store that
much data per file in the first place.

I haven't used 9P for anything yet, so I don't know much about how it
behaves, but it looks very versatile.  I'll create a 9P backend for fskit,
if it proves more useful than FUSE (also gives me a chance to seriously use
9P for something).


[0] https://en.wikipedia.org/wiki/Doors_%28computing%29

On Sat, Dec 6, 2014 at 8:21 AM, Marty <martyb@xxxxxxxxxxxxx> wrote:

> On 12/06/2014 04:56 AM, Mike Bird wrote:
>> Hi Jude,
>> You certainly have some interesting ideas.  If you decide to proceed
>> you'll have a lot of work and you may or may not succeed.  But the
>> only way we move forward is by people trying and sometimes succeeding.
>> --Mike
> I think other aspects of Plan 9, like union directories and per-process
> namespaces, work synergistic with p9 and complete the scheme, so
> this gets complicated. People have been proposing Plan 9 ideas for
> years, and incorporating them into the kernel and userspace. (I think
> /proc and /dev are examples).
> If possible, I would plan it like a regular project. Read Bell Lab's 9p
> spec and note what the authors see as the solution to Unix.
> Compare this to Linux 9p (probably time for rtfsc), and make sure it's
> more than a partial or token implementation.
> Suppress gag reflex and read dbus spec. Then look at the kdbus tree and
> note what the *authors* see as the solution to themselves. :)
> kdbus is what such a project will be competing with.
> Then compare p9 to kdbus in the kernel, rtfsc-wise and testing-wise, in
> a true apples to apples comparison (as much as possible).
> Maybe run some benchmarks and other tests. Then convert a package or
> two to the new "IPC" scheme to see how it works.
> It's probably worth documenting the problems and proposed solutions,
> before committing to writing code, so get sufficient comment and buy-in.
> Offhand, this looks like a massive project.
> All of this is new to me, so I would have to be a follower and not a
> leader in something like this, but it looks promising.

Other related posts: