Re: suggestion

[Rik van Riel <riel@conectiva.com.br>]

On Mon, 12 Jun 2000, root wrote:

> > 1) it's a hell of a lot easier and less time consuming, because you don't
> > have to constantly re-evaluate everything
> 
>  You contradict yourself. Newer releases will introduce new
> portions of code and we'll have to start over again each time.

The code may change often, but that doesn't mean it changes
fast.

Most of the time a kernel patch consists of a dozen or so
updated drivers, some updated architecture specific file and
maybe a few small changes to the core kernel.

Two kernel versions a week may seem impressive, but if you
look at kernel 2.2.0 and 2.4.0-test1 side by side you'll see
that the code in both kernels is still remarkably similar...

> > 2) it's what people experienced in this kind of work do - see *BSD,
> > especially OpenBSD. does anyone remember their kernel-schedule?
> 
>  Not me. I don't know much of *BSD. I'm trying to figure what
> _we_ would need, not them.

So look at OpenBSD a bit closer. Maybe our needs are somewhat
different from theirs, but I suspect that they're largely the
same. And even if they turned out not to be, there's no reason
not to learn from their mistakes.

I think I left my Wheel Reinvention Kit somewhere under a pile
of crud in the garage and I don't really feel like digging it
out...

> > 3) there's no real reason to NOT do it this way.
> 
>  Same as there's no reason not to start with the code that won't
> be changed and proceed to the evolving versions.

True. There are a number of things to keep in mind here:

1) the code changes often, but relatively slowly
2) our project will be a long-term, ongoing project that
   never really finishes
3) one of our goals is to make the Linux kernel more secure
   (not some fork of the source tree, but the kernel people
   actually use)

Because of that I think we may as well start with the 2.4
source base and work from there. I mean, we could start with
2.2, but by the time we've finished there nobody will be using
it any more. By working on the same version the developers are
working, OTOH, we will be able to work towards a long-term
improval of all Linux kernel source code.

>  Yes. My production system is frozen at 2.0.38. But that's not a
> majority. We don't have exact figures at hand, so let's not
> appeal to any whimsical majority.

Also, it makes little sense to start working towards today
next week. That way we'll always be behind the facts and
will always remain cleaning up an 'old' code base. IMHO it
would be more useful to work _with_ the developers to make
sure that future kernel code is clean and correct.

regards,

Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.

Wanna talk about the kernel?  irc.openprojects.net / #kernelnewbies
http://www.conectiva.com/		http://www.surriel.com/


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/