sigma1

[Espen Skoglund]

[Jeremy ]
> 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.

It's not really fair to be talking about a specification (and
implementation) which has not yet been released is it?  Anyhow, when
you said Pistachio I was assuming that you were referring to
L4Ka::Pistachio, not NICTA::Pisctachio-embedded.

>> 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.

BSP?

> 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.

Right.  Looking at source code for example applications is fine.
Looking at the kernel source to figure out how are supposed to work is
a bad idea.

>> 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

Sure.  You definitely should be more specific about the API you're
talking about in the future, though.  When one says "Pistachio" most
people consider it to mean L4Ka::Pistachio and the Version X.2 API.

	eSk