Martin Young my@siroyan.com writes:
I'm interested in putting L4 on a 'new' processor core [...].
Cool! Can you elaborate on why you're interested in doing this?
Is there a recommended route for doing this? I suppose that I could either write a new implementation from scratch or port an existing one. L4Ka looks quite attactive as it already exists for more than one platform and it's available under the GPL. OTOH the L4/x86 reference manual is so short that a new implementation doesn't look too daunting. Would anybody like to guess how long either route would take?
(Take the following with a grain of salt: I am the main designer and implementor of the Fiasco microkernel.)
In the past, no L4 implementation has ever been reused and ported to a different architecture by a group other than the originator's. It has been the L4 gospel that it is cheaper to just do a new implementation.
This has worked well so far. I estimate the cost to be somewhere between .5 and 1.5 man years, depending on the level of sophistication you want to achieve (real-time? SMP?) and the tests you have (on the x86 we have L4Linux; when L4Linux stops crashing, you're done ;-).
AFAICT, one of the goals of the L4KA project is to prove that a portable L4 implementation is both possible and feasible. I believe that the L4KA hackers can put their kernel on a new architecture in a matter of weeks. However, I have no idea how approachable their source code is or whether they have any design documentation or implementation notes available. If they have something, though, I'm certain they'd be happy to share it with you. (They are actively researching microkernel portability. Maybe they'd even like to hire you!)
Strictly speaking, Fiasco has been developed for x86 CPUs without special regard to portability. However, Fiasco's object-oriented design encapsulates hardware specifics as much as other subsystems. I believe that it can be refactored quite easily to support more than one architecture. Therefore, I personally would look into porting Fiasco. Of course, I'm in a better position that you are, because I am well accustomed with this beast, but I believe that Fiasco's structure is quite intelligible if you are a bit into OO design. I also have some design documentation available for the asking. I and my group would be happy to help out with our experience.
That said, I believe that both options for porting an existing kernel do not take significantly shorter than just doing it yourself, given you don't know the source base. Just like developing a new system, porting a kernel requires understanding it, and that can take time.
I'm also wondering how stable L4Linux (particularly the 2.2.x kernel version) actually is. I see on the mailing list that some simple commands can crash the kernel, but is this typical? I don't want to run anything large like a RH distribution but a stable kernel+bash would be great.
No, this is not typical. L4Linux is quite stable and happily boots Linux to multiuser mode and runs XFree86, Netscape, XPilot and the likes.
If I were to write or port an L4 MK I expect that initial versions wouldn't be well optimised for my CPU architecture. In this situation how would it's performace compare to (for example) mach?
Michael Hohmuth wrote:
Martin Young my@siroyan.com writes:
I'm interested in putting L4 on a 'new' processor core [...].
Cool! Can you elaborate on why you're interested in doing this?
I work, as an OS developer, for a company which is producing said new core. It looks like we're going to have a non-MMU-capable tiny OS and a much heavier slower microkernel. I'd like us to also have an MMU-capable microkernel with a smaller footprint and better perforance. I don't have any particular application in mind.
Is there a recommended route for doing this?
Therefore, I personally would look into porting Fiasco. [with explanation of why]
I've downloaded the source of two implementations now (L4ka an Fiasco) and all the docs I can find. I'll proably spend a little while looking at these things then try to work out which code base makes most sense to me.
Thanks for your help.
Hi,
Thought I might be able to contribute something to this discussion. I am a PhD student at the University of York (UK) , Real-Time Systems research group and I've been looking at portability/ real-time / microkernels for the past year and half.
Our main interest is hard-real-time/ safety critical for applications in aircraft and suchlike. I studied the L4 kernel API/ paradigms and although my main interest is research (ie. towards a PhD!!) have started a partial port to a PowerPC 603e based on the MIPS port by Kevin Elphinstone:
http://www.cse.unsw.edu.au/~disy/L4/MIPS/
I chose this route because of the similarity of the two architectures and the wide availability of documentation for this kernel port. There is a document (Inside L4/MIPS) that documents a lot of the important parts of the code, especially low-level stuff (IPC path, system calls, memory management) and explains the architecture dependant design decisions/optimsations/restrictions. It is used actively at the university for teaching and research so there is always likely to be help available.
I was an absolute novice at the beginning of this and for an experienced OS implementor with experience of the architecture that the implementation is for then I wouldn't expect an implementation to take longer than 6 man months. For what its worth here is the strategy I followed:
* Look at my requirements ie. Flexible memory management for hard tasks. Minimal restrictions to application developers.
* Spend some time understanding the L4 kernel paradigm / API. Particularly with respect to IPC / fpage mapping.
* Understanding the design / implementation decisions used in the particular implementation (MIPS)
* Understanding the target architecture / machine. eg for memory management design. Does it have a fixed pagetable lookup algorithm?
* Sketch the design for the target architecture. There may be kernel API changes. For instance I separated tasks into threads/ address spaces as some L4 people have suggested will be done in the future.
* Looked at code resuse. I resued the page table lookup code (C) from L4/MIPS with virtually no changes. I resued (sort of) the assembler by an almost 1-1 mapping between instruction sets.
* Documented all design decisions / implementation decisions right through to assembler because its the only way I (or anyone else) would know what the hells going on!!
The trouble with this top down approach is that a lot has to be done before you get any working code. I found the MMU stuff could be done seperately (because I needed to get some results for a paper.
I have no experience in how Fiasco differs from L4/x86 but supporting HRT systems has implications for a new implementation. I have recently published a conference paper (ECRTS 01) on supporting virtual address spaces for Hard-Tasks on the PowerPC and have suggested solutions for a number of other architectures. (Apologies for the unashamed promotion of my own work :-) email me if you would like a copy) There are a number of other issues to do with IPC and scheduling.
Oh dear this has turned into a very large mail.
Cheers
Mike
http://www-users.cs.york.ac.uk/~mikeb/index.html
with may have some useful info. on it in the future (or perhaps not)
Martin Young (my@siroyan.com) said:
Michael Hohmuth wrote:
Martin Young my@siroyan.com writes:
I'm interested in putting L4 on a 'new' processor core [...].
Cool! Can you elaborate on why you're interested in doing this?
I work, as an OS developer, for a company which is producing said new core. It looks like we're going to have a non-MMU-capable tiny OS and a much heavier slower microkernel. I'd like us to also have an MMU-capable microkernel with a smaller footprint and better perforance. I don't have any particular application in mind.
Is there a recommended route for doing this?
Therefore, I personally would look into porting Fiasco. [with explanation of why]
I've downloaded the source of two implementations now (L4ka an Fiasco) and all the docs I can find. I'll proably spend a little while looking at these things then try to work out which code base makes most sense to me.
Thanks for your help.
-- Martin Young, working for: | Phone: +44(0) 1454 615151 Siroyan Limited, Bristol Design Centre, | Mobile: +44(0) 7855 758771 West Point Court, Great Park Road, | web: www.siroyan.com Bradley Stoke, Bristol BS32 4QG. UK | email: my@siroyan.com
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.
This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
l4-hackers@os.inf.tu-dresden.de
-
Martin Young -
Michael Hohmuth -
Mike Bennett