[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Starting point
> > Of course, a completely different route to follow would be to start
> > with
> > the 2.0 kernel, since it is bugfix-only at this stage.
>
> This shall be decided by the majority of the community.
Umh, let me tell you how it look from a slightly different point of view.
I'm still happy with 2.0.38, an old and lazy dino, so bear with me, please,
because I'm likely to stay in minority :)
Development kernels, as well as recent production versions enjoy massive
attention from active kernel developers. This code is being written,
tested, patched, reviewed constantly. Let's say it's `in.'
Recent cap issue with 2.2.14 was detected and eliminated fast enough,
_without_ any help from LKAP per se. `We' are just forming our community,
but `they' could already fix the problem.
Unlike that, stable or old kernels get less and less eyes, despite of the
fact that there are many people like me who are not planning kernel
upgrades real soon, because there's no practical need. It ain't broke, so
leave it alone.
What if we organize not by kernel versions, but by subsystems, or
whatever other (buzz)word shall we use. We can start working on the core
functionality, like task scheduling, moving to `abstraction' layers like fs
or network, then descending to hardware and so on.
Of course, in this case roadmap can be more complicated, but it's well
worth it IMHO. I believe it's easier and more consistent to take signal.c
from every kernel we have at our disposal and dissect it to see how it's
written, to study its evolution and to identify possible problems by code
comparison.
What would you say?
---
"Teddy - I suppose Mummy and Daddy are real, aren't they?"
Teddy said, "You ask such silly questions, David. Nobody knows what
'real' really means. Let's go indoors."
Brian W. Aldiss, Supertoys Last All Summer Long
Kernel-audit: discussion list for security and the linux kernel
Archive: http://mail.nl.linux.org/kernel-audit/