Abstract: [1. Keep the Hurd interface(s) to Mach as portable as possible,
so that most/each Mach implementation can be used.
2. There are other Mach implementations besides gnumach with a
richer or different set of features. Besides using the Hurd
as main OS-Server on top of those Mach(s), one could also use
the Hurd as 2nd OS-Server, inheriting X11, networking etc...
3. Integrating the latest version of the Linux device drivers
to the Hurd should be further investigated,
probably by moving them into user-land.]
Some of us are currently trying different implementations of Mach
with the Hurd, using i386 or other platforms like alpha [starting
off a Linux- or FreeBSD native system in most cases]. It would
be very useful to agree on a minimal set of Mach interfaces that
should be allowed in the Hurd servers and libraries, so as to
maintain maximal portability.
One way to ensure this would be to try the Hurd with every Mach
implementation we can get our hands on (consider this as a kind
of torture test for the Hurd). Some of the most popular Mach(s):
gnumach i386 (of course ;-))
oskit-mach i386, alpha (status?)
cmu-mach i386, ... (original Mach 3.0, up to MK83)
utah-mach i386, ... (precursor of gnumach (with/without Lites))
norma-mach i386, ? (any pointers to the fixed OSF NORMA impl.?)
rt-mach i386, mips (http://www.mkg.sfc.keio.ac.jp/
http://info.isl.ntt.co.jp/rtmach)
<???> (anyone using other Mach(s)?)
As Roland pointed out, Mach should be multiboot compliant, but
Satoshi reported that hurd/boot/boot.c was ported to NTT RT-Mach
so as to boot the Hurd as 2nd OS server from Lites. This approach
could also be taken in similar situations. BTW, we should really
try the Hurd as 2nd OS-Server besides {the Hurd, Lites, US, UX, OSF/1}.
This would also be a great portability test and a very valuable setup
for developers (you get multiple consoles, X11, networking etc for free
directly from the Unix-Servers that had more time to mature than the Hurd).
Why bother with other Mach implementations besides gnumach? The main
reason is to use Mach features that didn't make it in Utah's Mach4 and/or
gnumach like:
Real-time and multimedia support in RT-Mach,
Realizing binary compatibility of Linux-, *BSD-, and other OS-ABI
by redirecting system traps to an emulation library. (done in Lites,
using the emulation vector features of Mach).
Multi-computer and cluster support with
NORMA-IPC and XMM in CMU-Mach (early support but somehow broken),
in norma-mach (fixed NORMA support, XMM abandoned but
at least somehow fixed)
KKT and DIPC in <???> (believed to be faster than NORMA-IPC/XMM)
Task migration and Load Distribution on top of NORMA-IPC and XMM
Support for embedded systems in misc. Mach implementations (eventhough
the Hurd in its current state may be overkill in
such systems! :-))
<???> Other new features that are being developed in research labs
on some version of Mach.
One very important issue, that should be dealt with in this context is
to further investigate, how to integrate the (latest version) of the
Linux device drivers in the Hurd. This has to be done in a way, that
should remain as independent as possible from the actual Mach kernel.
IMHO, the only viable way to do this, would be to move all Linux device
driver code into user-land and to provide a (user-land) glue-code (or
source code preprocessor a la MiG or a perl script) that would use the
generic device_*() interfaces of Mach itself to access the real hardware
at the bottom half of the driver code (I'm not sure wether this interface
is general enough in all Mach(s), but it could be added to every Mach if
needed). The upper half (interface to Linux) could be virtualized through
a simple library. [The glue-code in gnumach is interesting _and working_,
but unfortunately not very portable to other Mach(s), AFAIK.]
The issue of moving the Linux device drivers to user-land, so that they
can be used by all Mach implementations, is of general interest to the
whole Mach community (and probably even to Linux kernel hackers, we could
at least agree on a set of macros for low-level hardware access?).
We should discuss this in a broader audience, once we come up with a
coherent concept.
-Farid.
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.
