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