Re: hurd does NOT need /hurd
Anthony Towns <aj@azure.humbug.org.au> writes:
> On Mon, May 20, 2002 at 08:39:12AM +0200, Marcus Brinkmann wrote:
> > > Hrm? Why are you typing "/hurd/foo" in your settrans command instead of
> > > "/servers/foo" then? What's /servers for?
> > /servers is an area where active translators reside.
>
> Ah! That would be a very /proc-ish namespace then.
Well, in one way maybe. Except that in /proc the idea is deliberately
to export a file interface for things. Mostly read-only (is there
support for Plan-9 style writing to /proc things?). Each service
lands as a file in /proc, and you read that file to find out about it.
/servers is explicitly not that; if you open a file in /servers you
generally can't read it at all. Instead, you will communicate with it
by some protocol totally other than the filesystem protocols, which
are being used just as a naming scheme to get to it in the first
place.
> Which makes /hurd be the namespace for inactive servers, and /servers be
> the namespace for activer servers. Hrm. If I understand this right, it
> probably would've been tidier to have:
>
> /hurd/msdos
> /hurd/active/socket/2
>
> under a single hierarchy. "active" should probably be spelt "actv" for Unix
> compatability ;)
I can't tell whether you understand here, because we already use
"active" and "passive" in a very specific sense here.
An "active" translator is the dynamic existence of a mount point.
A "passive" translator is a static record set up by settrans; when
someone attempts to open the file, the specific program is run and
hooked in as the active translator.
So the very same name gets an active and passive translator; that's
the whole point. :)
> Well, for the "settrans" stuff, the purpose is to make some files
> available in the filesystem. That a new process happens to start up to
> do it, and that you have to give the name of the executable, is really
> fairly irrelevant to your purpose.
Actually, no. You're thinking of translators as a way to get a file
to show up, but the whole design of the Hurd is that you should think
of them as a way to hook into a different program entirely.
Thomas
--
To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: