Re: vk_l4 -- CVS Setup

[Farid Hajji]

> <snip>
> > A real pager like UVM would need to:
> 
> What is UVM exactly and you have any documents describing how is works
> and why it works that way?
The UVM copyright line reads:
  Copyright (c) 1997 Charles D. Cranor and Washington University.

UVM is Mach-VM developed further. UVM replaced Mach-VM recently in
the *BSDs, resulting in substantial performance improvements w.r.t.
memory access. I'm just mentioning it, to show that UVM is being
heavily used in real-world systems with very good results.

I'll write more on UVM here as soon as I'm through with first-reading
of the code in NetBSD and the corresponding research papers ;)
Meanwhile, you may want to have a look e.g. at the public (kernel)
interfaces of the UVM system in e.g. NetBSD sources under:
/sys/uvm/uvm_extern.h. Ich can mail you this file directly, if
you can't get it easily.

I'm suggesting to use UVM not only because it is technically better,
but also because of its Mach-VM heritage, which would make it an ideal
candidate for the Hurd too.

> > This is absolutely Hurd-neutral and can be used by all personalities.
> >=20
> > Please don't confuse vk-l4/nameserver/ with l4hurd/portserver/.
> 
> I don't know a nameserver is it the Right Thing to do. We already have
> the file name space and the proc server. The original mach nameserver
> was abandoned because it wasn't needed afaik. Could you tell us the
> details of it and why it is needed?
You need a nameserver to look up the access ports of independent tasks.
Let's say that you want to access the superdriver task. Under Mach, you'll
have to get a port to this task, under L4 you need the task/threadID pair
of the service thread in this task. Without this information, you can't
RPC the server, neither under Mach nor under L4 (or any other microkernel
that lacks a nameservice of some kind).

So you need to ask a nameserver on a well-known port resp. task/threadID
for the actual port resp. TID of the server that you want to contact.

As you pointed out, the traditional Mach development environment provided
a nameserver task (sname, snames, snamed or whatever it was called) that
could be RPCed via library calls. Obviously this mechanism had to be
bootstrapped somehow, or else you couldn't know where sname was located.
The bootstrap problem was solved by hardcoding the access port of sname
into the lookup_*() functions provided by Mach under OSF/1 or by the
C-Library (or more exactly libmach) on other mach-based systems.

sname proved to be a potential bottleneck if used heavily. For this reason,
the Hurd decided to distribute the nameserver across the filesystem.
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. Because in the Hurd, every file_t is a
port, it was obvious that the names could be mapped pretty regularly
on top of the filesystem. Frequent requests could be distributed
down the root to lower portions, thus lowering the burden on the '/'
translator itself.

The other Hurd way to get a port to a regular hurd _process_ (as opposed
to a Mach task) is to use 'proc'. In this sense, proc could be seen as
a kind of nameserver for tasks with Unix-like semantics, that registered
themselves with 'proc' (via fork()). This is rather limited, because
a process can only register itself, not e.g. a set of different services
with 'proc'. Contrast this with a file_t translator that could map/
register names under subdirectories like:
  /servers/somename/service-1
  /servers/somename/service-2
  ...

You may now ask, why I'm proposing an old-fashioned nameserver for L4,
rather than simply using the Hurd's distributed nameserver mechanism.
Well, there are a few compelling good reasons to separate both mechanisms
here:

1. You must at least bootstrap the Hurd _and_ the root filesystem server,
   before you can use nameservice under the Hurd. This is not a problem
   under Mach, because Mach already knows about its pager and Mach also
   already provides devices to access the disks etc... Under L4, things
   are not so readily available. To bootstrap the Hurd, 'boot' will
   need to get the 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.

   Put another way: this is the old chicken-and-egg problem ;-)

2. A vk-l4 nameserver would be useful to other personalities like l4linux
   (modified) or anything else as well. Such personalities would like to
   use L4 (or vk-l4) without having to boot the Hurd first, just to get
   a nameserver. The responsibilities of the Hurd's nameserver (mechanism)
   and the lower-level VK/L4 nameserver are distinct and serve different
   purposes. I could expand more on this, but would prefer to postpone
   the discussion of this for later.

3. A vk-l4 nameserver would be extremely useful, when L4 will provide
   network-wide unique TIDs. A L4 nameserver task would then provide
   access to remote as well as local TIDs, so that we could contact
   remote pagers, remote drivers and so on. Imagine booting one Hurd
   using local disks and, say, L4linux using remote disks. This would
   be possible through a network-aware L4 nameserver running on every
   L4 node. [Well, I guess that the kernel would at least be called
   L5 then ;)].

   Distributed, network-wide TIDs are not a new idea. This is basically
   the same as what used to be NORMA/IPC in the Mach environment, but
   which proved to be rather hairy. I don't know wether L4 will evolve
   in this direction, but I could very well imagine some developments
   there. The network communication parts will most likely happen to
   be user-land anyway, but a network-wide L4 nameserver would still
   be useful.

There are other technical reasons that advocate spearating the Hurd's
and a VK/L4 nameserver. One of these reasons is proper layering. The
VK/L4 infrastructure resides one layer below every OS personality,
including the Hurd. 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.

> Jeroen Dekkers

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.