Hi,
I've just started to look at L4 and I'm using L4ka::Pistachio as a starting point. I'm trying to read as much as possible and have found a reference to sigma1, but no docs on it. Can anyone elaborate on what this is for?
Thanks, Luke.
Luke A. Guest <laguest <at> archangeli.demon.co.uk> writes:
Hi,
I've just started to look at L4 and I'm using L4ka::Pistachio as a starting point. I'm trying to read as much as possible and have found a reference to sigma1, but no docs on it. Can anyone elaborate on what this is for?
AFAIK, sigma1 disappeared a long time back - I've been working with Pistachio for about 18 months now, and have never seen it!
Given the name, I suspect that it probably formed part of a previous implementation of platform memory management. On more recent Pistachio kernels, a privileged thread, sigma0 'owns', all platform memory on startup. Thread pagers (root task, by default) obtain memory by requesting it from sigma0. Sigma0 has disappeared from the latest Pistachio kernels as well, so even the information above is version dependent.
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.
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.
You don't mention whether you have done so or not, but you would be well advised to start off with the Iguana release. Iguana presents a much more friendly API on L4, and is also a very useful source of programming techniques.
Good luck Jeremy
Thanks, Luke.
On Wed, 2006-05-24 at 11:56 +0000, Jeremy O'Donoghue wrote:
Luke A. Guest <laguest <at> archangeli.demon.co.uk> writes:
Hi,
I've just started to look at L4 and I'm using L4ka::Pistachio as a starting point. I'm trying to read as much as possible and have found a reference to sigma1, but no docs on it. Can anyone elaborate on what this is for?
AFAIK, sigma1 disappeared a long time back - I've been working with Pistachio for about 18 months now, and have never seen it!
I just wanted to know what it was as I'd seen it mentioned, but nothing else was documented, then I saw references to it in relation to persistence.
Given the name, I suspect that it probably formed part of a previous implementation of platform memory management. On more recent Pistachio kernels,
AFAIK, sigma1 is not implemented in the Pistachio kernel, although there is persistence work going on on l4ka.org.
a privileged thread, sigma0 'owns', all platform memory on startup. Thread pagers (root task, by default) obtain memory by requesting it from sigma0. Sigma0 has disappeared from the latest Pistachio kernels as well, so even the information above is version dependent.
Really? I've not seen this, which version? I'm using 0.4 Pistachio from the downloads area.
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.
Tell me about it, I'm also relearning the OS theory as I go along at the same time. I'm totally confused by memory handling at the moment.
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.
Yeah, I'm trying to find as much as possible to see what others do in certain situations.
You don't mention whether you have done so or not, but you would be well advised to start off with the Iguana release. Iguana presents a much more friendly API on L4, and is also a very useful source of programming techniques.
I have got the Iguana source code down, but it's difficult to find something specific when you don't really know it very well.
I'm attempting to document my efforts here: http://www.geocities.com/munkee_chuff/ Feel free to read it and email me with anything I might get wrong.
Thanks, Luke.
[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?
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.
Any hack in the kernel implementation are either temporary solutions or used for testing purposes. Don't rely on them.
eSk
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
[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
Espen Skoglund <esk <at> ira.uka.de> writes:
[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).
[deleted]
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.
Apologies for slow response: GMANE was down yesterday.
My major mistake was that I didn't appreciate fully the distinction between Pistachio::L4Ka and Pistachio::NICTA-embedded before answering. I certainly apologise for any confusion which that caused.
Given where I started, (i.e. assuming NICTA-embedded), I don't think it's entirely unreasonable to mention an API change which is arriving imminently on that platform (after careful checking, public download version is 1.1; my version is 1.1.1).
[deleted]
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?
Board Support Package. It's a pretty commonly used acronym. The BSP is the set of customizations which make it possible to at least boot a kernel on some hardware. It's basically the code which lives under the platform directory, so the code in platform/pleb2 is the BSP for the Pleb2 board.
[deleted]
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.
I will take care to be clear when I am talking about the embedded kernel API, rather than X.2 in future.
Jeremy
l4-hackers@os.inf.tu-dresden.de
-
Espen Skoglund -
Jeremy O'Donoghue -
Jeremy O\'Donoghue
-
Jeremy O\\\'Donoghue
-
Luke A. Guest