lkml.org 
[lkml]   [2000]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Re: Move of input drivers, some word needed from you
On Tue, Aug 22, 2000 at 12:19:39PM -0400, Eric S. Raymond wrote:
> Linus Torvalds <torvalds@transmeta.com>:
> > It is NOT true that "shared code means less bugs". People, wake up!
>
> You've ignored what I see as Rogier's main point. It's not "shared
> code means less bugs" per se, it's "shared code means better test
> coverage".
>
> Think of each user as testing testing a semi-random sample of the
> driver's state space for correctness. Then coverage on each line of
> driver code is proportional to the number of users per driver.
>
> Sharing code is a way to increase the test population for the shared
> parts, which increases expected test coverage on the shared parts,
> which is good. It's especially good because the shared parts tend
> to have subtler bug signatures than the unshared parts (data structure
> corruption is harder to diagnose than a device lockup), so the better
> test coverage happens exactly where it's most needed.
>

I don't think this is true for drivers. It is ok if the difference between
the hardware is really small.

But often this is not the case, at least after some "generations". Code gets
more complex then necessary.

Sharing code for drivers then often means that somebody detecting a bug can't
fix it. And even for maintainers it is difficult to exclude side-effects.

An example is tulip.c in 2.2. It has several bugs which don't get fixed.
One bug i.e. is for DC21041 the interface does not work any more if
it loose the connection for several minutes to the switch/hardware. This bug
is described often. And probably some people detected the reason (it's an error
in the autoconfiguration, every time it detects a tx-link it is switched
to back to bnc).

I have a fix which works for me, but I have no real idea what will do for
other dec chips where autoconfiguration works rather differently.

As a version change of tulip.c affects so many different cards the version
of 2.2.16 is not replaced by a newer version of Donald Becker.

If you have a look at tulip.c you will realise that most code is not really
shared. It was an error to have one big driver for DC21040, DC21041, DS21140,
DS21143, "Lite-On 82c168 PNIC, ...

And I claim that this is a typical situation for hardware. Hardware evolves.
After some time the really shared code is small.

Greetings,

Wolfgang Walter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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