[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: vk_l4 -- CVS Setup
From: |
Farid Hajji |
Subject: |
Re: vk_l4 -- CVS Setup |
Date: |
Tue, 30 Oct 2001 04:00:05 +0100 (CET) |
> > 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?
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. 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). 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.
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 ;-).
> > 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. 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.
-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.
- Re: vk_l4 -- CVS Setup, (continued)
- Re: vk_l4 -- CVS Setup, Farid Hajji, 2001/10/29
- Re: vk_l4 -- CVS Setup, Farid Hajji, 2001/10/29
- Re: vk_l4 -- CVS Setup, Niels Möller, 2001/10/30
- Re: vk_l4 -- CVS Setup, Espen Skoglund, 2001/10/30
- Re: vk_l4 -- CVS Setup, Farid Hajji, 2001/10/29
- Re: vk_l4 -- CVS Setup, Neal H Walfield, 2001/10/25
- Re: vk_l4 -- CVS Setup,
Farid Hajji <=
- Re: vk_l4 -- CVS Setup, Neal H Walfield, 2001/10/30
- Re: vk_l4 -- CVS Setup, Christian Ceelen, 2001/10/25
- Re: vk_l4 -- CVS Setup, Niels Möller, 2001/10/25
- Re: vk_l4 -- CVS Setup, Farid Hajji, 2001/10/29
- Re: vk_l4 -- CVS Setup, Yoshinori K. Okuji, 2001/10/25
- Re: vk_l4 -- CVS Setup, Farid Hajji, 2001/10/29
- Re: vk_l4 -- CVS Setup, Lars Reuther, 2001/10/30
- Re: vk_l4 -- CVS Setup, Farid Hajji, 2001/10/29
- Re: vk_l4 -- CVS Setup, Neal H Walfield, 2001/10/30
- L4 device-driver framework (was Re: vk_l4 -- CVS Setup), Michael Hohmuth, 2001/10/29