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/