[okl4-developer] Questions about the current state of Wombat/Iguana

[Abi Nourai]

Hi there,

That's a good bunch of questions there.  Hope my answers are helpful.

On 28/01/2008, at 2:15 PM, Subcommander l0r3zz wrote:

> After reading  various papers on the OK Labs and NICTA sites, I have  
> some questions about the current state of Wombat....
>
>
> 1) Does a Wombat process run in a EAS? Or does it share address  
> space with Iguana in any way?

OK Linux (Wombat) user processes are all created in an external  
address space.  They don't share an address space with Iguana.  This  
is required to preserve compatibility with normal Linux  - most  
importantly to preserve fork() semantics (which would be challenging  
in the iguana address space - being SAS)


>
> 2) Obviously busybox  is a Wombat process, if I execute something  
> like :
>
>        vi foo &
>
>    does this fork a new Wombat process (PD)  with a separate AS or a  
> thread in the same AS?

so the shell will execute fork() which will lead to the OK Linux  
syscall thread making a call to iguana server to create a new thread  
in a new, separate & external address space.

>
> 3) If I load another program into the root image, like say, emacs,   
> but not link it into the busybox glob, will this execute in the same  
> AS as the busybox process that spawned it or is it a separate L4  
> (Wombat) process (PD) ?

Also separate.

>
> 4) Is there network support for ethernet devices other than pcnet32?

Good question.  Really what's lacking is support for DMA in OK Linux -  
something that has a very prominent place on our product roadmap and  
in fact is actively being worked on.

>
> 5) I've heard that there isn't support for DMA devices in Wombat, it  
> that is true, how does the hd driver work?

The HD driver works but without DMA - so it's very slow :)

>
> 6) Can Wombat  userland programs execute L4/Iguana calls?  
> specifically, can I send IPC to a service that is not in my AS?


Because OK Linux user processes run in a separate, external address  
space from the Iguana SAS, their interaction with Iguana server is  
very limited (there's probably some things they can do that don't  
require being part of the SAS but certainly not most).

Note that OK Linux user processes can technically invoke OKL4 kernel  
system calls directly.  However this might break assumptions that OK  
Linux (i.e. the para-virtualized Linux kernel) is making and lead to  
havoc.

Feel free to discuss a specific use case if you have one in mind -  
we'll recommend the best model/architecture for getting what you  
want.  One model that we've used in the past is:

OK Linux user process (eg. busybox) <---------> OK Linux kernel  
(Wombat) <-------> External service

The advantage of this is that the OK Linux kernel (Wombat) can  
abstract a communication channel to the external service in a manner  
where the endpoint at the OK Linux user process end looks just like a  
pipe/fifo/socket/standard linux construct.  Then the OK Linux user  
process doesn't really need to be made aware of anything OKL4  
specific, which is good.  And because OK Linux (Wombat) is an iguana  
app, he can interact with other Iguana apps (i.e. processes running on  
top of Iguana).

>
> 7) I'm told that I can write a Wombat driver that can communicate  
> with an L4/Iguana service, this implies that the code in arch/l4 can  
> execute L4 IPC, no?

Sure ... Wombat is an Iguana app and is able to interact freely with  
other Iguana (OKL4) apps.

>
> 8) Is there DMA and/or network support in Iguana?

In iguana server ?  Not at all ... that stuff would be built on top of  
iguana using our driver framework.

>
> 9) Is there support for multi cores in Iguana?

OK, intermission.   By Iguana do you mean Iguana server ?  Or do you  
mean the Iguana environment?  If you mean the latter, let's call it  
the OKL4 environment (or even OKL4 OS).

Iguana server itself is single threaded.  The publicly-available OKL4  
microkernel running underneath (most likely) only supports a single  
processor ... however multi-processing capabilities are one of the  
most important things to OK and we certainly hope to release versions  
of OKL4 for x86 that take advantage of multiple hwthreads, cores,  
processors at some point.


>
> 10) Does any of this run on 64 bit architectures  (ia64 ) ?

Older versions of L4 used to support Itanium (ia64).  Internally, the  
OK team has had much success in porting OKL4 to x86-64, and we hope to  
make that available in accordance with our product roadmap.  You can  
expect the x86-64 kernel to be able to run 32-bit and 64-bit L4  
threads side by side (which eg. means you can run 32-bit and 64-bit  
guest operating systems side by side).


Regards
Abi