Re: vk_l4 -- CVS Setup

[Neal H Walfield]

> The Hurd's nameserver is distributed accross the whole filesystem.

There is no `nameserver': every server is its own nameserver.

When a Hurd process is started, it has several special ports, among
there are a send right to its current root directory port
(cf. <hurd/hurd_types.h>).  Note that I say `its current root
directory' and not `the current root directory'; every process can
have its own root directory.

When a process opens a particular resource, it does a
file_name_lookup.  This gets translated (by libc) into several
dir_lookup rpcs (cf. <hurd/fs.defs>).  file_name_lookup works by
querying the root directory with the path and asking it to expand it
and return a port to the named resource.  This often fails.  However,
this is merely a retry: the file system will set DO_RETRY to
FS_RETRY_MAGICAL, RETRY_NAME to the remaining path components and
RESULT to the new server to query.  Why?  Because that server does not
know the child's name space -- and should not.

At this point, it is then up to the client to finish the expansion.
It sends another dir_lookup to the new server and is either given the
resource or, possibly, is told to that yet another retry is necessary.

Thus, the root directory only knows about its name space out to its
leaves -- nothing more.  Additionally, each server controls a piece of
the hierarchy; there is no central authority.

> In the Hurd, servers can register themselves by attaching somewhere
> to the filesystem (settrans). To get a port to this server, you just
> open() the location on the filesystem where the server attached.
> Because every file_t _is_ a port to the server providing it, you've
> got an easy way to lookup a server via the filesystem.
>
> Just one example: A server providing services a, b and c could
> register like this on the Hurd filesystem:
>
>   /servers/gandalf       << the name of the server is gandalf
>
> To access gandalf (knowing its name), simply open this path.
> gandalf now provides a, b and c as services. It therefore
> generates a subdirectory with three (well 5, if you add . and ..)
> entries like this:
>
>   /servers/gandalf/a
>   /servers/gandalf/b
>   /servers/gandalf/c
>
> If you need service b, you open /servers/gandalf/b and voila, you've
> got a port to the specific server thread. The generated subdirectory
> is dynamic in nature. One example: priviledged users would see more
> entries there than normal users:
>
>   [...]
>   /servers/gandalf/admin
>   /servers/gandalf/peek

This is up to the file system; there is nothing terribly special going
on here.

> Things can get worse, if you know that you can attach other servers
> at completely different locations on the filesystem (not only
> under, say, /servers, which is a pure convention). You could add
> a new server under:

There is not convention.  Anything that attaches to the file system is
a server.  If I `mount' a file system on /home, there is a server
listening on /home.

> This is extremely tightly bound to the filesystem philosophy of the Hurd.
> Frankly, I'm not good enough at the Hurd sources to see a way to cleanly
> isolate this mechanism so that it could run-alone as a generic L4 task.
> Other Hurd hackers could enlighten us here.

This you will need to explain; all of the magic happens in libdiskfs
(et al) dir-lookup.c and libc's file_name_lookup.

After this, I am basically lost.