Messages in this thread | | | From | (John Alvord) | Subject | Re: [PATCH] Re: Move of input drivers, some word needed from you | Date | Wed, 23 Aug 2000 15:55:29 GMT |
| |
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/
| |