[This is quite offtopic for the Hurd lists. As Roland pointed out, the Hurd lists are for discussing things clearly pertinant to existing Hurd software. Please direct any replies to this message to [EMAIL PROTECTED]
>>>>> Farid Hajji writes: FH> 1. I'm trying to put the Hurd on top of a 'vk' (virtual kernel) FH> API that will have to provide a minimal set of semantics required FH> of microkernels. Ultimately, there would be many vk libraries to FH> choose from, e.g.: vk-mach, vk-l4, vk-linux, vk-freebsd, FH> vk-solaris, ... Each vk would implement the ukernel semantics FH> (vk-API) in a different way, using what's available underside. This is exactly the task that I began pondering four years ago. At the time, Thomas had made a few thoughts in this direction with libmom, but it was recently dropped because the bits of the API that it provided were not fully thought out. Figure (http://fig.org/figure/) is my own attempt at this task, and it is quite ambitious. Indeed, you could call it a virtual machine, plus a compiler/interpreter, designed to be portable to any environment (at least, every environment I know of). What distinguishes Figure is that it is small, and that it is a metacompiler. The goal is not to have the same *binary* interface on all platforms (which you seem to imply via your `vk' idea), but to have the same *source* interface, which can be optimized on a per-platform basis (either by the compiler, or by the source code itself specifying a platform-dependant optimization). (Note that I consider `Posix/ANSI C source code', `Java bytecodes', `i386/BIOS assembly', `NetBSD/Sparc', `GNU/Hurd Mach/i386' and `human-readable interface documentation' all to be `platforms' when it comes to Figure.) This is a *much* different approach than trying to define a specific binary API that all programs must conform to. That's an idea that scales very, very poorly the more platforms you add. Portability and efficiency are contradictions unless you are talking about a compiler, not an ABI. (Relative) platform-independence is the thing that makes Mach so difficult to optimize aggressively. A lot of thought has gone into this design, and I think I'm making good progress (having really started implementation in February), but as I said before, this is an _ambitious_ project. The code so far does not do justice to my plans, which is why you find a lot of abstract, pie-in-the-sky debate in the mailing list archives. FH> vk-mach would map tasks, threads and ports to the familiar mach FH> counterparts, vk-l4 would do something similar as far as possible FH> and vk-{guest-os} would simulate ukernels with real Unix FH> processes and pthreads. I'm working on Figure{portable-c-on-guest-os}, because I think it's the most popular free software developer's platform (i.e. GNU/Linux and GNU/Hurd, *BSD, and others provide such an environment). It's also the (free) platform that gives the least control over the underlying machine, so it poses the most interesting challenge (IMO). FH> IMHO, we should brainstorm and then agree on such a minimal FH> interface that will have to be provided by those vk-[*] FH> libraries. Please feel free to park your brainstorm on [EMAIL PROTECTED] It's currently averaging 7 messages a week, so don't worry about being swamped with mail, and I'd be happy to contribute. You, and anybody else, are welcome to discuss pie-in-the-sky plans for universal portability on that mailing list. Such discussion is quite on-topic there, and you may even see your ideas implemented in Figure (even more likely if you do the work yourself ;). If Figure turns out not to fit your needs, then that's fine, but I'd still love a chance to collaborate and solidify our designs together, rather than blindly stumbling into uncharted waters. Anyway, my 30-second spot is already over, ;) -- Gordon Matzigkeit <[EMAIL PROTECTED]> //\ I'm a FIG (http://fig.org/) Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
