Portability [was: Porting the Hurd to L4...]

[Gordon Matzigkeit]

[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
figure@fig.org.]

>>>>> 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 figure@fig.org.  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 <gord@fig.org>  //\ I'm a FIG (http://fig.org/)
Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)