Re: Hurd on Mach on GNU/Linux (verion 0.0.0)

[Farid Hajji]

Hi John,

> http://tobeyhutchison.com/jtobey/Hurd/gnumach-otop.tar-0.0.0.bz2
> 
> What this hopes to be is enough of GNUMach ported to POSIX/Linux to be
> able to run the Hurd binaries where they have been sitting on my disk
> since the last time I booted them up.
Wow, I'm truly impressed! I didn't yet download nor tried it, but
will do so on my development NetBSD/x86 box, just to be sure that it
really is POSIXish enough for my needs ;) As you've correctly guessed,
you're not the only one interested in a user-land mach emulation that
permits hacking on the Hurd inside a POSIX (restricted to x86-platforms)
system. [I hate frequent rebootings too ;-)]

Mach/POSIX seems to provide exactly the benefits that the VK/POSIX
scenario is supposed to implement. Since you're implementing Mach
rather than the simpler VK, running current Hurd programs would be
(hopefully) possible without any changes to the Hurd sources. In the
future, I'd prefer that we gradually move away from Mach and put the
Hurd sources on top of a simpler VK. If (and when) this transition is
made, you could hack on Hurd sources and run them on VK/POSIX on your
development POSIX machine and on VK/Mach on top of Mach.

People familiar with the VK concept can skip the rest of this mail.

On the l4-hurd mailing list, we're discussing the need for and form of
a layer between the [micro]kernel and the Hurd that will isolate the
Hurd from a specific kernel that it is running on top of. I called
this layer VK (virtual kernel). The idea is that the Hurd (and glibc)
should use _only_ functions from this layer to access the VK. VK
itself will relay those calls either directly to its underlying
[micro]kernel or will emulate missing functionality in user-land.

Depending on the underlying [micro]kernel, there will be many variants
of VK: VK/Mach, VK/L4, VK/POSIX etc... A VK will provide to its users
(which could be the Hurd or some other OS personality like user-land
Linux, user-land BSD, ...) a uniform set of "system calls". This is
somewhat similar to POSIX, which provides a set of system calls to
user-land programs. Just like there exist multiple implentations of
POSIX kernels (Linux, BSDs,...) there will be multiple implementations
of VK (VK/Mach, VK/L4, VK/POSIX...), all providing the same set of
system calls to OS personalities (and programs running on bare metal,
emmm, bare VK).

Concerning the Hurd, a naive approach would suggest that VK system
calls be exactly the same set of syscalls than Mach provides. This
way, VK/Mach would simply be a set of empty macros and be up and
running on Mach right away.  Furthermore, the Hurd would not need to
be modified to run on top of this simplistic VK. VK/POSIX would then
have to emulate as much Mach as possible so that the Hurd can run
there. This VK/POSIX would be exactly what gnumach-otop is intended to
provide!

Unfortunately, setting VK=Mach is not a good idea. If proved very
difficult to emulate enough Mach on top of L3 (a precursor of L4).
Moreover, and even more importantly, some characteristics of Mach
stand in the way of kernels providing faster IPC like L4. If we ended
up setting VK=[big subset of]Mach, VK/L4 would be slower than
necessary and Hurd/VK/L4 would be even slower than Hurd/VK/Mach or
Hurd/Mach. This would defeat the whole purpose of porting the Hurd to
L4 in the first place.

So VK will need to provide a sufficiently small subset of Mach to be
useful at all. This involves changing the Hurd sources to use less mach-
specific things that will not be present in VK. We're currently in
the process of assessing the Hurd requirements of such a VK and of
means to implement VK/L4. Once the set of VK syscalls stabilizes,
VK/POSIX (and most likely VK/Mach) could be rather quickly implemented.
Then, the Hurd sources will need to be modified to use only this
stable set of VK syscalls. Such hacking could be effectively done
either on Hurd/VK/Mach or Hurd/VK/POSIX, the latter being what John
is intending with gnumach-otop right now.

Okay, enough general talk for now and back to hacking...

> ps, OTOP means "On Top Of POSIX" but there are a few Linux and i386
> dependencies still in there.
> John Tobey <jtobey@john-edwin-tobey.org>

-Farid.

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