How can Minix 3 be so small
cquark at gmail.com
Wed Jun 27 04:24:14 CEST 2007
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.
On 6/27/07, Gernot Heiser <gernot at nicta.com.au> wrote:
> >>>>> On Tue, 26 Jun 2007 17:39:51 +0200, "Neal H. Walfield" <
> neal at 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
> 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).
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the l4-hackers