Ya know I don't really think the way we go as far as kernel by kernel or
file by file really matters. I think what matters how organised it is.
I believe either way will work as long as the backend of it all it stable
and clean.
Though I'm retarded, what do I know : )
On Sat, 10 Jun 2000, you wrote:
> > > 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?
--
Bryan Paxton
"How should I know if it works? That's what beta testers are for. I
only coded it."
-- Linus Torvalds.
Kernel-audit: discussion list for security and the linux kernel
Archive: http://mail.nl.linux.org/kernel-audit/