[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [task #6612] Overriding the system's default servers

From: olafBuddenhagen
Subject: Re: [task #6612] Overriding the system's default servers
Date: Sun, 11 Mar 2007 18:10:51 +0100
User-agent: Mutt/1.5.13 (2006-08-11)


On Sat, Mar 10, 2007 at 05:36:40PM +0000, Thomas Schwinge wrote:

> It should be allowed for the system's default servers to be easily
> overridden.  (By setting environment variables, for example.)
> This is partly implemented for the `crash' server (albeit largely
> untested) and has been begun for the `exec' server (see task #6611)
> and is missing for the others.
> Especially, being able to easily override the `pfinet' server running
> on `/servers/socket/2' would offer a large scale of possibilities.

Plan9 has a rather simple solution for this: They have local namespaces
(i.e. each process can have a different view of the filesystem), which
allows easily installing alternative servers in place of the default
ones for individual programs/users/whatever.

The Hurd however, although technically possible, doesn't implement local
namespaces in the standard filesystem servers; and having some
reservations about local namespaces, I don't necessarily consider this
an omission that should be fixed...

It is possible though to give processes a different filesystem view, by
using a proxy FS server. (In many situations, unionfs probably can serve
as such a proxy, though it doesn't cover all cases I think; and not
being optmized for this specific use case, it's probably not very

Of course, using such a proxy FS to replace only a single standard
server is often overkill, so a solution with environment variables is
probably desirable neverthelesse.

I do not like environment variables very much, however. IMHO,
per-process environment should rather be accessible through a special
location in the filesystem. (Maybe this can be implemented on top of the
existing environment handling in the Hurd?) In fact, systems offering a
/proc filesystem, already allow access to the environement through the
FS -- but in a rather obscure fashion. A user-friendly approach for that
seems desirable.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]