Re: [PATCH] Re: Move of input drivers, some word needed from you

From: John Alvord (jalvo@mbay.net)
Date: Wed Aug 23 2000 - 10:55:29 EST


On Wed, 23 Aug 2000 07:05:41 -0400 (EDT), "Mike A. Harris"
<mharris@meteng.on.ca> wrote:

>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?

Are there any lessons to be learned from the VFS layer which
encapsulates the file system support in Linux?

john alvord
-
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/



This archive was generated by hypermail 2b29 : Wed Aug 23 2000 - 21:00:08 EST