Messages in this thread | | | Date | Wed, 23 Aug 2000 07:05:41 -0400 (EDT) | From | "Mike A. Harris" <> | Subject | Re: [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/
| |