How can Minix 3 be so small

[Espen Skoglund]

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.