figure vs. libvk [was: Portability]

[Farid Hajji]

Hi Gordon,

>  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.
> 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).
Thanks for the hint. This is really interesting, but, as you've put it,
quite ambitious. I've just downloaded the latest figure release and will
have a look at it.

> 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).
libvk is not intended to be a _binary_ interface, but a true API.
At least, its public interface should remain constant across different
platforms/ukernels. I'm still investigating what the Hurd _really_
needs from Mach and how this can be simplified. Some abstractions
do already appear and I'll summarize later.

Thanks,

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.