Re: Why GNU Mach is so different?

From:

Farid Hajji

Subject:

Re: Why GNU Mach is so different?

Date:

Sun, 30 Dec 2001 18:37:15 +0100 (CET)

> RT. The Hurd is not a real time system. It doesn't make use of RT. The
> Hurd runs on RT Mach, though. So you can use the real time extensions in a
> Hurd system, but you can't rely on the Hurd servers or the C library to do
> any RT'ish things for you. Are the real time changes free? We might
> include them by default in the future, if we find someone willing to
> port and maintain them.
Exactly!
> BTW, I guess some stuff was disabled (SMP) when the Linux device driver glue
> code was integrated, and never resurrected. With oskit-mach, that part of
> the kernel has been cleared up again, and there is hope now to get stuff
> like SMP support back into our mach.
Agreed. But we'll definitely need some SMP machines to work on.
Its quite hard to find SMP motherboads with chipsets compatible to
both Linux, FreeBSD-CURRENT (with SMPng) and the yet-to-be-maintained
-and-updated Mach SMP code [and maybe a SMP-version of L4 as well] :-(.
If there is real interest, we can scan the above mentioned SMP codebases
for chipset requirements and post a summary here of what is needed. Someone
may have a list of hardware vendors for us too...
> > I want to work with distributed systems and clusters until the finish of
> > my course (college). I know that many work are being done with L4, but
> > in my understanding, when someone say that L4 is "working in process", I
> > see in Mach work done with many tests, researches and results waiting to
> > be improved and used.
>
> i think some work can be done here, not only on the kernel level (which you
> need), but also in the Hurd servers. I think passing ports over networks
> etc can be done in user space on the Hurd (and maybe should). Beside those
You want to migrate _Mach_ ports over the net? This essentially means that
you have to transfer the message queue, but also leave a forwarding/
redirecting proxy at the old location until all clients have updated
their destination portnames. If you move the ports further, you quickly
develop a chain of forwarding proxies (which is bad). This is exactly
the problem with VM objects in the old Mach VM that was only recently
being solved in NetBSD's UVM (by early-collapsing the chains).
> technical features you need, there is, for example, the requirement to have
> a network-wide unique process id for a task. Thomas calls such a network
> of Hurd systems a "collective". I guess if you want to do distributed
> systems in a Hurdish way, collectives are the way to go. The concept exists
> only in Thomas head, though, so you will have to nag him a bit to tell us
> about his ideas.
Network-wide unique identifiers like task-IDs, ports, etc... are a nice
thing to have. One idea may be to organize all nodes of a collective
in a distributed kind of (hurdisch) filesystem. IDs would then be
simple paths and could be located with some kind of distributed
lookup() functionality:
/collective1/ # namespace for collective #1
/collective1/ipc/ # ipc namespace (ports...)
/collective1/ipc/machine1/ # ipc namespace for machine1
/collective1/ipc/machine1/port1
/collective1/ipc/machine1/port2
...
/collective1/vm/ # namespace for VM objects
/collective1/vm/machine1/vmobject1
/collective1/vm/machine2/vmobject25
...
Every member of a collective whould have to provide "translator-like"
functionality and register itself with the collective. Or if you prefer,
each machine will be "translator", serving its own set of ipc, vm, ...
namespaces. Now, _that_ would be hurdish!
-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.