Re: 9p/plumber to replace D-Bus?
On 12/12/2014 10:46 PM, Joel Rees wrote:
2014/12/13 3:44 "Miles Fidelman" <mfidelman@meetinghouse.net>:
So... in all of this thread, I have yet to see anybody actually talk
about 9p or plumber - details, and more importantly, in comparison to D-Bus.
People are concerned about impacts to their particular use cases, which
I understand
I mean, 9p has been in the Linux Kernal for years (as compared to, say,
kdbus), and it is actually used in some interesting places (erlang-on-xen,
libvirt-to-quemu communications) where both the functionality and
performance are rather critical.
Does anybody have any direct, technical experience here?
It does not seem to be widely used, but the more I look, the more I find
examples of people asking the same questions.
I have been thinking about installing plan 9 on an old box here, will
probably do so. Right now, that box is my wedge for learning how to manage
an openbsd box. (Plan 9 has some really interesting stuff, but I wouldn't
be able to do some of my necessary work on it.)
So, I've been reading the plan 9 website.
Near as I can tell, p9 and plumber are less a replacement for the fluff
that is dbus than a replacement for the infrastructure dbus is built on.
Yes, it's a core infrastructure replacement.
My guess is that dbus on p9/plumber would be so obvious and dead simple
that we'd go back to dbus on sockets/signals/mmap/so-forth, and say to
ourselves, "Oh. Why did we bother extnding the desktop manager paste buffer
like that?" (Of course, I'm already saying that anyway, so YMMV.)
That was my impression when I first read about Plan 9. It's dead simple
and has an "obviousness factor," although my summary may not be
accurate:
1) The virtual hierarchical filesystem is used for local and network-wide
access of all devices, storage, networks, and hosts.
2) The network is the computer, with security domains enforced by
distributed agents (factotum). Per-process namespaces combine with
the distributed filesystem to enforce security at all levels.
3) Per-process local and global namespaces are enforced by the security
model. (If you can't see the resource, you can't access it.)
4) IPC uses a simple text message protocol (plumber) over 9p, which
also provides a simple RPC mechanism. Sockets and APIs are not used,
but an enhanced (bidirectional) version of Unix pipes is provided.
5) A reinvention of the GUI showcases all these features. I have not
looked closely but I don't see much chance of replacing both D-Bus
*and* the GUI in the near term. It's probably just too ambitious.
Even ignoring 5) for the moment, that is a lot, just to replace D-Bus.
Is the entire Plan 9 model required for D-Bus replacement? If not,
which pieces can be used, and should they be full or partial
implementations?
If you don't implement the whole "network is the computer" model, do
you just open up the debate that runs through this thread, about
multi-user/multi-seat Unix? Do you end up with the worst of both worlds?
Is it all or nothing, a complete replacement of userspace? In that
case, maybe it would better to start with a Debian Plan 9 port
(but that seems like a non-starter for various reasons).
Due to issues like this, I am nowhere near proposing a real project,
but this is still at the idea stage.
--
Joel Rees
Reply to: