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, 22 Aug 2000, Linus Torvalds wrote:

>On Tue, 22 Aug 2000, Eric S. Raymond wrote:
>>
>> Linus Torvalds <torvalds@transmeta.com>:
>> > But the "common code helps" thing is WRONG. Face it. It can hurt. A lot.
>> > And people shouldn't think it is the God of CS.
>>
>> I think you're mistaken about this.
[SNIP]
>Quite frankly, the mentality that "we must share all common problems,
>whether it makes sense or not" has resulted in untold woes. Usually it
>starts out small. You add one more device. It obviously makes sense to
>just tweak the code a bit. You add one more. You'll add some special case
>code that only really matters for that one, and you hope that you got the
>other cases right.
>
>Eventually, you'll have code that spans 5 generations of hardware, where
>the first generation and the last one basically share _no_ commonality
>except for the common heritage. And they share a lot of the code, because
>they have been written to do things the same way, even if it really
>wouldn't make much sense any more.

Up until now, I thought the idea of code sharing like that was
_good_ for Linux as it simplified development, testing, etc.. and
it made for one driver to drive many things instead of a single
driver per piece of hardware.

When you shine a flashlight on things however like you did just
now, it makes such code sharing seem a lot like M$ Windows, where
things get added and added, and backwards compatibility cruft is
left in forever. Things just keep growing until they burst at
the seams.

When seen from that angle, I think I'd rather have separate
drivers for _some_ stuff than a kludgy driver that breaks
whenever a new generation comes out - changing a few lines of
code.

One thing that makes Linux configuration simpler though is this
shared code. The ne2k driver for example. Any ne2k card I've
ever used, worked instantly more or less without hunting down
some special driver for a particular card.

I think we need a happy "medium" of some sort. Not an all or
nothing split. If a driver or group of them become unmanageable,
then maybe they should be split into the minimum number of
separate drivers as can be, while retaining a core of some
kind. I'm not sure how possible that is in reality, but it
sounds good in thought.

If splitting a driver, makes driver development for new hardware
easier, and doesn't make administration a nightmare, then by all
means it should be done. The question is where do the lines get
drawn, and which drivers will get split up. All of them? Or
only problematic areas?

TTYL


--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate

Try out Red Hat Linux today: http://www.redhat.com
ftp://ftp.redhat.com/pub/redhat/redhat-6.2/


-
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:38    [W:0.104 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site