Re: Starting point

[Daniel Taylor <dante@plethora.net>]

Organizing somewhat by specialty is probably good, but only if we take
a critical lesson from the OpenBSD project and others like it:

  If something is a bug in one place, it is probably replicated elsewhere.

So say you find an overflow condition in the Vortex driver. There is a
good chance that code has inheritance from NE2k and that other drivers
inherit from it.  Check all the drivers in drivers/net for obvious 
occurences and post to the list so that others looking at other parts
of the kernel can possibly spot less obvious recurrences.

The other thing to remember is to be very careful, a lot of bits of code
that might look like a problem at first glance are simply the objects of
some very wierd optimizations, with problem cases being detected and
eliminated elsewhere. That is part of what makes this so challenging.

Daniel Taylor                Embedded and custom Linux integration.
dante@plethora.net           (612)747-1609

On Sun, 11 Jun 2000, root 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?
> 
> 


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