sigma1

Jeremy O\\\'Donoghue jeremy.odonoghue at gmail.com
Wed May 24 16:14:19 CEST 2006


Espen Skoglund <esk <at> ira.uka.de> writes:

> 
> [Jeremy ]
> > Sigma0 has disappeared from the latest Pistachio kernels as well, so
> > even the information above is version dependent.
> 
> What?!?  Sigma0 has always come with the kernels and will always do.
> How else are the applications supposed to get access to memory?

I'm currently working with a prerelease of Pistachio based on the N2 embedded 
architecture. This is not yet available for general use, and does contain 
changes over X.2 (as, to a more limited extent, does N1).

Under N2, a new syscall is added to support memory mapping by pagers, in part to 
enable deterministic execution time for map/unmap operations on embedded 
systems.

> > Learning about L4 in general can be frustrating as, being in
> > significant part, a research vehicle, much of the background
> > documentation is in conference papers and thesis extracts, and dates
> > quickly (L4::Pistachio is evolving very rapidly).  The background
> > material is still useful, but you need to be aware that it's not
> > always relevant to the latest releases.
> 
> Actually, the Version X.2 API and the corresponding L4Ka::Pistachio
> implementation is evolving rather slowly.  Or put in a better way, the
> API is getting close to feature complete and there are as such not
> many more changes to the kernel (for the current API).
> 
> > The source code is your friend here (although the user manual and
> > refman are reasonably up to date). Most of the code is well written
> > and structured (if sparsely commented), although it requires very
> > good C++ and CPU platform knowledge to follow in detail.
> 
> The source code is *not* supposed to be your friend.  This is not
> Linux.  The refman is the definite source for kernel behaviour; and
> yes, the refman is updated whenever the API changes (with a changelog
> history entry in the preamble).  If there's something unclear in the
> refman then please ask.

This depends on what you are trying to do. If running L4 on a hardware platform 
for which a BSP exists, I would agree with you (at least to a point). The API is 
well defined and clear pre and post conditions are specified.

For beginners, however, the refman has a very high information density. The 
Iguana sources (for example) provide a very good source of examples of how to 
use the API.

As an example, I would contend that it is not straightforward, from reading only 
the user manual and refman, for an L4 beginner to understand what s/he would 
need to do to create a set of threads which live within partially overlapping 
memory spaces (e.g. to support a shared memory area). Iguana sources provide 
well written examples of how such operations can be constructed from the L4 
primitives.

For my own case, I work on a complex application-specific embedded environment 
for which board support is not available for public download. In this scenario, 
the source is most definitely *my* friend. 

> Any hack in the kernel implementation are either temporary solutions
> or used for testing purposes.  Don't rely on them.

I'm not sure that I'd use the word 'hack' to describe the NICTA N-series 
Pistachio APIs, but I would agree that these are (of necessity) changing faster 
than X.2

Jeremy





More information about the l4-hackers mailing list