Re: L4Env

[Lars Reuther]

Farid Hajji <address@hidden> writes:

> Are you currently working on a pager with a mach-like vm_*() interface
> which could be used instead of Mach's vm_*() calls in the Hurd or in,
> say, Lites? I'm currently thinking of implementing such a pager by
> modifiying the UVM sources of NetBSD [UVM is better than Mach- or
> BSD-VM, because it proactively tries to collapse the vm_object chains
> that tend to build up in Mach/BSD-VM]. This pager should be accessible
> through IDL calls which will be wrapped in a user-level vm_*() library
> similar to Mach's vm_*() syscalls.

There is no need for a central pager in L4 (although you can build
one). Any thread in the system can be the pager of a thread,
pagefaults are mapped to L4-IPC, the pager replies with a mapping of
the appropriate memory page. 

Our memory management consists of two main elements, dataspace
managers and region mappers. Dataspaces are container for any kind of
memory (files, anonymous memory, ...). They are managed by dataspace
managers (e.g. file systems, anonymous memory managers,
...). Dataspaces can be attached to regions of the address space of a
L4 task. 
Region mappers are pager threads, usually we use one region mapper in
each L4 task which is the pager for all other threads of that
task. The region mapper doesn't resolve the pagefault itself, instead
it looks up the dataspace which is attached to the pagefault address
and calls the dataspace manager which manages that dataspace to map
the appropriate page. 

With this model many of the usual memory management functionality can
be implemented efficiently. E.g. to share a dataspace you just have to
attach the dataspace to several address spaces.

For more see "The SawMill Framework for VM Diversity"
(ftp://ftp.cse.unsw.edu.au/pub/users/disy/papers/Aron_PJLED_01.ps.gz)
 
> > Closely related to L4Env is an IDL compiler for L4 IPC. We used Flick
> > so far, but we are currently switching to our own IDL compiler, DICE.
> Which bindings will DICE produce? I assume that they well be at least
> C and/or C++ bindings. Will they be CORBA/OMG compliant (as specified
> in the omg C and C++ specs)? Will the IDL language itself be CORBA/IDL
> compliant? IIRC, DICE or some other compiler I recently saw, used
> non-compliant IDL syntax. Hmmm...

For various reasons we moved to a DCE-like IDL syntax. Check the DICE
website (http://os.inf.tu-dresden.de/DICE).

> > We already implemented some of the L4Env components, the
> > documentations can be found on the L4 Developer's Bibliography web
> > page. We hope to release a snapshot in the next 1 or 2 months. 
> That would be great! Could you please cross-post the announcement
> to l4-hackers and l4-hurd as well? Thanks!

Of course.

> Will L4Env be both L4Ka/Hazelnut and Fiasco compliant? Are you prepared
> to support V2-API when it will be released?

In the end L4Env will support all L4 version, it is one of the goals
of L4Env to hide most of the L4 API details. Right now I'm using
Fiasco, but we already tested it roughly on Hazelnut.

> > Helmuth wrote his Diploma thesis about the driver emulation framework
> > (in german), a short position paper in english and slides of a
> > presentation can be foud at
> > http://os.inf.tu-dresden.de/~reuther/helmuth.pdf
> > http://os.inf.tu-dresden.de/~reuther/helmuth_slides.pdf
> Thanks for the hint. I'll grab the thesis as well, if it is available.

Ask Christian (address@hidden).

Lars

-- 
Dipl.-Inf. Lars Reuther          Dresden University of Technology
Department of Computer Science   Operating Systems Research Group
Phone: +49 (351) 463-38401       Fax: +49 (351) 463-38284
address@hidden     http://os.inf.tu-dresden.de/~reuther/