Re: vk_l4 -- CVS Setup

[Neal H Walfield]

> 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 ;-)

The same problem exists in Mach and the Hurd.  Take a look at how we
bootstrap the Hurd (either the new of the old server boot code) and
the simplicity of this solution should become quite evident.  I assume
that a similar implementation could be done for L4 and the Hurd.

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

Two Hurd cannot talk to each.  Why should they except via an (as to be
written) distributed interface?

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

I am not convinced.  And, I see no reason that L4 would be making any
upcalls.