Re: vk_l4 -- CVS Setup

[Neal H Walfield]

>> Two Hurd cannot talk to each.  Why should they except via an (as to be
>> written) distributed interface?
> First of all, using two Hurd's is but one possibility. The most frequent
> situation would be running, say, L4Linux and the Hurd concurrently [I know
> there will be some struggle accessing common partitions on the disks
> and other devices, just like in the case of two sub hurds].
>
> Even with two sub hurds, I could imagine running one sub-hurd on one
> pager, and another sub-hurd on another pager.

There can only be a single default pager for Mach.  This is
effectively `outside of Hurd'.

> I could even imagine
> booting one sub-hurd from one root-device and other sub-hurd from
> another root-device (on a different partition or even on a different
> disk). 

You could imagine?  But, this is the way it is.

> So at least they would need to agree how to bootstrap and an
> elegant way to do this, would be to use a lower-level nameserver.

Why?  They do not currently.

> BTW, it could be possible to add an interface to the Hurd, so that
> two sub-hurds could interact somehow (e.g. agreeing on the use of
> devices etc...). This would be very interesting work, even for
> pure Hurd/Mach hackers right now ;-).

This is why I was referring to as the distributed interface.  However,
it does not have to be any difference then a Hurd on another computer
accessing a device (although the implementation will clearly be a bit
different).

>> > 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.
> Suppose that you provide nameservice via the Hurd. Now suppose that you
> want to start the L4Linux server and have that server access the common
> UVM-pager running on top of L4. Without hardcoding TIDs, the L4Linux
> server bootstrapping code would need to ask the _Hurd's_ nameserver
> (accessed via a well-known L4 TID belonging to, say, the Hurd's root
> file server) for the TID of the common pager. 

Again, the default pager is a property of Mach, not the Hurd.

> Put another way: Hurd-
> independent requests would come from other parts (via L4) and will
> need the Hurd's nameserver system to provide basic services. If you
> look at it, it's _kind_of_ L4 doing an upcall to the Hurd OS personality.
> This is terribly confusing, mostly because of mixing layers.

I think you should take a look at the boot program; this has already
solved this problem.