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 <[EMAIL PROTECTED]> -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
