lkml.org 
[lkml]   [1997]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: too much untested code in new kernels
Date
> Finally I would like to address the argument 'go run 2.0.XX if you want
> a stable kernel'. I don't need a stable kernel. But I do want a kernel
> where ALL code gets tested at least ONCE by the people who write it
> BEFORE they hand it to Linus.
>
> Is that asking too much?

Maybe yes, maybe no.

Two of your examples I have opinions on.

1) The basic module code as seen in 2.1.18 _did_ work on the Alpha.
As it turned out, several of the i386 patches I made to the wrong
development tree so they got lost, but...

As for its inclusion in 2.1.18, perhaps I should have been more
clear for Linus' time-stressed benefit in my snapshot message to
him, Jacques, Miguel, and Andreas that the tools to use the kernel
patches wern't ready for prime time. I don't fault him for that
though, as I did mention that there were generic bug fixes in
there that should be incorporated now, and I didn't split them out.

2) How can you protect against munged patches, as affected the
watchdog driver? When they are noticed, they'll get fixed,
but they must be noticed.

I discovered for myself while trying to build all of the
drivers to determine how they were affected by the module
patches that it is virtually impossible to build a kernel
with _everything_, because some drivers require parameter
knowledge to even build that I don't have. Or two drivers
that are not modules are mutually exclusive.

Therefore we must rely on the users of those drivers to speak up
and say the drivers are broken.


r~

\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.035 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site