[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) |
HI,
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
efficient...)
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.
-antrik-