Hi,
I just noticed that the Minix 3 kernel is under 4000 lines. I couldn't easily find numbers for Pistachio, but I guess it is comparable to Fiasco, which is about 15.000 lines (without the kernel debugger).
Could anybody explain why Fiasco is so big in comparison with Minix 3? From the difference in size I would expect that there is an essential difference in the feature set between Minix 3 and Fiasco. Or are the Minix lines just four times longer on average?
Bye,
Hendrik
Hi Hendrik,
Pistachio is about 10000 loc, I can't think of why in such difference. Pistachio makes a huge effort on portability so probably having such a good ABI-API segregation makes it longer in loc. but that is just a guess, do you know about IPC performance differences between MINIX and L4?
Thanks,
Jorge
On 6/26/07, Hendrik Tews H.Tews@cs.ru.nl wrote:
Hi,
I just noticed that the Minix 3 kernel is under 4000 lines. I couldn't easily find numbers for Pistachio, but I guess it is comparable to Fiasco, which is about 15.000 lines (without the kernel debugger).
Could anybody explain why Fiasco is so big in comparison with Minix 3? From the difference in size I would expect that there is an essential difference in the feature set between Minix 3 and Fiasco. Or are the Minix lines just four times longer on average?
Bye,
Hendrik
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Hendrik,
Could anybody explain why Fiasco is so big in comparison with Minix 3? From the difference in size I would expect that there is an essential difference in the feature set between Minix 3 and Fiasco. Or are the Minix lines just four times longer on average?
I recollect from a talk that Jorrit Herder gave about that Minix3 does not support paged memory: it uses segments for enforcing protection, which explains a large part of the difference you observe.
Neal
On Tue, 26 Jun 2007 17:39:51 +0200, "Neal H. Walfield" neal@walfield.org said:
NHW> Hendrik,
Could anybody explain why Fiasco is so big in comparison with Minix 3? From the difference in size I would expect that there is an essential difference in the feature set between Minix 3 and Fiasco. Or are the Minix lines just four times longer on average?
NHW> I recollect from a talk that Jorrit Herder gave about that Minix3 does NHW> not support paged memory: it uses segments for enforcing protection, NHW> which explains a large part of the difference you observe.
... which, among others, means that it cannot set up shared memory regions for high-bandwidth cross address-space communication.
The lack of portability has been mentioned too. Finally, L4 versions have a lot of fastpath code for low-latency IPC. My understanding is that Minix IPC is significantly slower than L4's. There are other optimisations in L4 implementations that add to the code size.
In general, you can always expect the need for a few extra things once a system moves from academia into the real world (as L4 has).
Having said that, Open Kernel Labs has stripped a fair bit of code from their OKL4 kernel (derived from Pistachio).
Gernot
Hi,
My observation is that kernels (inc. Minix3, Fiasco, and Pistachio) are often (sometimes much) larger than the official data. Maybe, they take different estimation methods? Or maybe the data are out of date? How about the headers and macros (which can notably influence loc.)?
I wonder if it can help if someone will measure and publish the loc. of these kernels with an unified and open standard. Of course, complete comparison between L4 and Minix3 is more valuable.
Regards,
Wei Shen
On 6/27/07, Gernot Heiser gernot@nicta.com.au wrote:
On Tue, 26 Jun 2007 17:39:51 +0200, "Neal H. Walfield" <
neal@walfield.org> said: NHW> Hendrik,
Could anybody explain why Fiasco is so big in comparison with Minix 3? From the difference in size I would expect that there is an essential difference in the feature set between Minix 3 and Fiasco. Or are the Minix lines just four times longer on average?
NHW> I recollect from a talk that Jorrit Herder gave about that Minix3 does NHW> not support paged memory: it uses segments for enforcing protection, NHW> which explains a large part of the difference you observe.
... which, among others, means that it cannot set up shared memory regions for high-bandwidth cross address-space communication.
The lack of portability has been mentioned too. Finally, L4 versions have a lot of fastpath code for low-latency IPC. My understanding is that Minix IPC is significantly slower than L4's. There are other optimisations in L4 implementations that add to the code size.
In general, you can always expect the need for a few extra things once a system moves from academia into the real world (as L4 has).
Having said that, Open Kernel Labs has stripped a fair bit of code from their OKL4 kernel (derived from Pistachio).
Gernot
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
There can't be any valid comparison between L4 and minix because the IPC mechanisms on Minix are obscenely crippled. They managed to wrestle defeat out of the jaws of a triumphant victory... =((((
The problem with L4 on the other hand is that it doesn't have an operating system wrapped around it in order to make it usable... I have a number of earth-shaking projects that I want to develop but can't for lack of a reasonably good IPC mechanism and no way to develop for L4 for reason of it's obfuscated system libraries and no development environment. =(((
Got a counterexample of an installable and usable L4 development system?
On 6/27/07, Alan Grimes agrimes@speakeasy.net wrote:
The problem with L4 on the other hand is that it doesn't have an operating system wrapped around it in order to make it usable... I have a number of earth-shaking projects ...
Can you share some?
Got a counterexample of an installable and usable L4 development system?
I think L4Env or Kenge + Iguana can do some work, through they are not mature yet.
IMHO (plese excuse me if it is not proper), we must have an unified development environment to make L4 more attractive and get more attentions.
I think L4Env is easier to understand for new comers, however most parts of the public release only support V2/X0 API, and there is never complete and up-to-date documentation or roadmap. The organization of source tree is confusing without a clear architecture. Various components and changes just emerge from time to time.
I believe if L4Env can support X2 API and is reorganized / redesigned to reflect an explicit system architecture with confusing legacy code discarded, it will be much more popular and can greatly boost the development of L4.
To me, Iguana is not good to understand, especially that there are much ambiguity in the specification. It is more like an academic report than a technical manual, and it seems that some concepts are still in development and so hard to correspond to source code. Moreover, Iguana is just a new single-address space "mono-kernel" in user level, it provides only a basic set of services and is far from enough to construct an usable system. We can not always rely on a virtualized Linux which eliminates the advantage of a u-kernel. I know that the new Iguana API is under development, however, again there is not a clear roadmap released.
It seems that both OS Group in TUD and ERTOS in NICTA focus more on their new L4 API. IMHO, seL4 and L4.sec may be great work in academic sense (and may relate to commercial considerations in future), but at present a strong development environment for existing kernels and APIs may be more important to expanding the influence of L4, and better meet the appetite of most open-source programmers (of course, these may not be what you concern).
As for Minix3, it grows fast since last year due to good organization and open strategy that attracts open-source programmers. And I think maybe one day, it will become more influential than L4 if things progress as now. An successful system may not be the one do best in specific aspects, but should be one that works.
Regards,
Wei Shen
Typically people use a tool that accounts for blank lines and comments when counting the lines of code. In Karlsruhe we've always used sloccount for our measurements (including for the code base being compared to). And yes, headers and macros aree accounted for as well.
That said, there are a number of other factors that drive up the line count. For example, in Pistachio there are currently two implementations of the mapping database (keeping track of mapping relationships). The old obsolete code has not been backed out yet because some of the architectures have not yet been converted to using the new code. This accounts for about 1000 sloc. Then there are a number of assertions and tracing/debugging features spread all around that do not contribute to any functionality (and is often not even compiled in) but that accounts for a few more thousand sloc. Of course, other projects also have debug features that must be accounted for --- Pistachio is not unique in that respect. All I'm saying is that even when using tools such as sloccount, it still won't tell you the whole story.
Lastly, the sloccount of a project also heavily depends on the coding style being used. Personally I favour a style where I don't try to cram as much as possible into a single line. For example, in Pistachio we always write:
if (...) { }
rahter than:
if (...) { }
Using the latter approach, i.e., not accounting for the '{' lines, would save us more than 3000 sloc over the whole Pistachio kernel tree (not counting the kernel debugger). Clearly, such a simple change in coding style does not have any effect on the complexity of the code. It does add quite a bit of overhead to the sloccount though.
eSk
[Wei Shen]
My observation is that kernels (inc. Minix3, Fiasco, and Pistachio) are often (sometimes much) larger than the official data. Maybe, they take different estimation methods? Or maybe the data are out of date? How about the headers and macros (which can notably influence loc.)?
I wonder if it can help if someone will measure and publish the loc. of these kernels with an unified and open standard. Of course, complete comparison between L4 and Minix3 is more valuable.
Hi Gernot,
Gernot Heiser wrote:
NHW> I recollect from a talk that Jorrit Herder gave about that Minix3 does NHW> not support paged memory: it uses segments for enforcing protection, NHW> which explains a large part of the difference you observe.
... which, among others, means that it cannot set up shared memory regions for high-bandwidth cross address-space communication. ...
It is possible to setup shared memory with the x86 segments by letting them overlap. The x86 segments just add an offset (and check the limit) to the segment local address. The result of this translation maps to a flat and untranslated (if only segments are used) address space.
Marcus
l4-hackers@os.inf.tu-dresden.de
-
Alan Grimes -
Espen Skoglund -
Gernot Heiser -
Hendrik Tews -
Jorge Torres -
Marcus Voelp -
Neal H. Walfield -
Wei Shen