[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