Date: Tue, 22 Aug 2000 11:01:26 -0700 (PDT) From: Linus Torvalds <torvalds@transmeta.com> To: "Eric S. Raymond" <esr@thyrsus.com> Subject: Re: [PATCH] Re: Move of input drivers, some word needed from you 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. I'll give you a rule of thumb, and I can back it up with historical fact. You can back up yours with nada. Simple rule of thumb: - sharing is good when it is true 100% sharing, no special cases, and there is nothing that has reason to avoid the sharing. Example: the VM layer. TCP/IP. The VFS layer. - sharing is bad when it's done to 90%, and people work at trying to avoid using the functionality that some other people want. Example: the SCSI layer. Parts of the IDE driver. Glibc vs kernel header files. 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. End result: bad organization for the new hardware, inability to sanely take advantage of the full features of the new hardware. Forcing people to leave old code in place, because it is work-arounds for bugs in hardware three generations gone. People end up having to thread very lightly because the developer probably has access to all the new stuff, but doesn't even have a way to test the old stuff any more - except by having users holler when he broke it by mistake when he added code to handle new cases. Face it. Every once in a while, you have to start afresh. Tell people that "Ok, we can't share this code any more, it's getting to be a major disaster". We've done this quite successfully several times. Each time it resulted in a better product. Which is exactly the reverse of what you advocate. Example 1: "hd.c" was left alone, "ide.c" was created. Some day, we'll hopefully leave "ide.c" alone, and create a "ata100.c" that only handles modern hardware. Example 2: 53c8xx driver. Which broke from the 53c7xx driver and just said "Screw it. That driver is too limited by the hardware it supports. I don't want to deal with it". See also the u14-34f driver vs ultrastor.c. Example 3: ne2k driver. Nope, the ne.c file was not just expanded to handle yet another card type. Yes, it shares the basic 8390 code anyway. This goes on and on and on. According to your logic, none of the above improvements should ever have happened. You're wrong. Linus - 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/