Re: vk_l4 -- CVS Setup

[Niels Möller]

Farid Hajji <address@hidden> writes:

> sname proved to be a potential bottleneck if used heavily. For this reason,
> the Hurd decided to distribute the nameserver across the filesystem.

Are you sure that performance was important for that decision? I
thought it was more like "We already have one mechanism for
associating objects with names: The file system. Any extra name server
is redundant, unneeded complexity, so let's just get rid of it", but I
don't really know.

> Basically, glibc is bootstrapped to access '/' (the translator for
> the root node) directly, then the names are mapped to the filesystem,
> e.g. like /servers/somename.

It's not really glibc that is bootstrapped. The normal way of starting
hurd processes makes sure that it has a few open ports at the start.
The list includes the process' stdio fd:s, it's current working
directory, and the filesystem root (which may or may not be the same
root as all other processes use).

> 1. You must at least bootstrap the Hurd _and_ the root filesystem server,
>    before you can use nameservice under the Hurd.

What boot does is bootstrapping the environment in which the initial
processes are started. I.e. it bootstraps what you call the "hurd name
service".

>    vk-l4 pager _and_ vk-l4 superdriver TIDs first. This would be
>    only possible through a vk-l4 nameserver [or the less than
>    optimal hard-coding of TIDs] at this stage.

If it's just these two (or less than, say, five), hardcoding things
seems reasonable to me. A name server that 1. never handle more than
five names, 2. handles the same names every time, and 3. is used only
for bootstrapping, seems overkill. But perhaps you imagine other uses
for the name server.

I'm not sure how the boot will work, but I imagine there'll be some
code somewhere that starts the initial processes. That code will get
the id:s directly and pass them on. In the current hurd, this happens
in Grub, Mach and serverboot (the latter just being made obsolete). A
separate name server seems superflous. The separate serverboot program
was needed because at least one of Grub and GNU-mach didn't support
more than one initial process. I'm not sure what L4 supports, but
given its minimalism it seems reasonable to have a user-level
serverboot-like program do the bootstrapping.

> It would not be wise to mix layers here by using upcalls from L4 to
> the Hurd (or something else), just to name one example.

L4 can use servers that are Hurd processes, if those processes use RPC
interfaces defined by L4. Examples include pagers and interrupt
handlers for user-level drivers.

Taking it a little further, if you want to get network transparent rpc
into L4 (not that I know if that is realistic), you won't put
networking inside L4, but define an rpc interface that takes, say, a
message in some form and an hostname/servicename/URL (possibly in a
numeric interned form). That rpc would be implemented by some hurd
process communicating with the hurd pfinet. So you could get network
transparent rpc and still use Hurd servers for doing the networking,
dns lookups etc. L4 need only know if the target of an rpc is local or
remote, and it wouldn't make much sense to put any more knowledge
about network things into L4 than just the local/remote distinction.
(if you think some more about it, L4 may not even need that).

/Niels