Re: vk_l4 -- CVS Setup

[Farid Hajji]

> > 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.
> The nameserver TID could be set at boot up. That's no problem at all.
> Either just push it on the stack of every first thread in an address
> space or slightly modify the pager-fault protocoll. In SC/OS we solved
> this by simply sending a special message (also using the 3rd dword) to
> the pager (this ID could be obtained by l4_lthread_ex_regs on myself) of
> a thread. The pager got the nameserver ID from the taskserver that
> searched for a loadable module named "nameserver" in the
> grub-module-list. After successful startup of this module the ID of this
> new task is forwarded to the pager. Thus the order of the loaded modules
> doesn't matter. Just something named "nameserver" is needed at boot up. 
> The "ext2-FS" driver asks its pager for the nameserver ID and register
> its service and export the mounted drive.
This is exactly what I was thinking about. Passing the nameserver's TID
either at task activation time, or via the initial pager is an excellent
solution!

> > 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.
> Couldn't be the Hurd nameserver be extracted that far from the Hurd,
> that it could already be used at startup time?
The Hurd's nameserver is distributed accross the whole filesystem.
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

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:

  /users/frank/my/own/stuff/someserver
  /servers/gandalf/subservers/anotherserver1
  /servers/gandalf/subservers/anotherserver2

Finding names would of course require knowing the path (or at least
the root of the path that you could traverse normally)...

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.

> > 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 ;)].
> The nameserver could just translate the incoming TID to a local TID. I
> see no need to put GUID into the µkernel. It would solve many problems,
> but I think many more will arise therefrom.
I didn't think this over. A lot of stuff could be done by redirecting
(or as you say translating) TIDs globally, probably via a nameserver.

What I'd like to see in L4 is a mechanism, that automatically redirects
every non-local TID to one (or more) local TID that will take care of
the call. Imagine that (giving GUIDs) a thread wishes to RPC a remote
server somewhere. It would construct a GUID giving the position of the
remote server and its own TID on the local system and then IPC directly
to this GUID. The kernel would redirect this IPC to the proxy which will
examine the GUID and forward it with appropriate means to the remote proxy,
which will itself forward it again to the destination.

This would be some kind of global chief mechanism, using proxies.

Probably, L4 wouldn't need to be modified after all. All that is needed
would be to RPC the namesever on a special TID. This special TID (let's
call it briefly the proxy-TID) will receive a message that contains
some kind of GUID and will act upon this GUID to forward the message
to a remove nameserver (using some kind of protocol). No L4 modifications
would be needed there. So I guess that GUIDs won't be needed after all...

> >    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.
> Agreed. That could be implemented at user-level. Without the GUID we
> just have to build a proper protocol for this.
Exactly. The only concern I'm having here is losing performance. If we
had GUIDs, L4 would quickly determine wether it should use local IPC,
or wether it should redirect the call to a preconfigured proxy-TID for
further processing. The decision would need to be done in kernel-space.
OTOH, the user-thread could decide wether to do local IPC effiently,
or to marshall a global GUID message into a local IPC directed to the
proxy. I don't know what would be faster here. Just a wild guess would
suggest that using kernel-time for this would unnecessarily reduce
parallelism and therefore be bad on a global scale. But this something
for the L4 wizards ;-)

> > 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.
> Is it possible to have more than on Hurd-nameserver within the same
> local system? Or did i miss something here?
As already said, there is nothing like a Hurd nameserver task. So if
you want more that one Hurd-"nameserver", you'll need to boot a
sub-Hurd. This would be roughly equivalent to booting two or more
L4Linux personalities.

Actually, even on a single Hurd system, the nameserver _is_ distributed
across the whole filesystem tree. One example: If you looked up 'blah'
under, say, /path/to/servers1/blah, you'll have asked the "nameserver"
/path/to/servers1. You could also ask for 'blah' using a different
"nameserver", e.g. by accessing: /another/path/to/blah: Here you'll
have asked the "nameserver" /another/path/to for the port to blah.
Lookups to /, /another, /another/path and /another/path/to could be
conveniently cached in the user-processes (to avoid asking the
intermediary "nameservers" more than absolutely necessary).

So there is no Hurd-nameserver in the conventional sense.

-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.