On Tue, 4 Oct 2005, Tomasz K³oczko wrote:
>
> On Mon, 3 Oct 2005, Linus Torvalds wrote:
> [..]
> > This is especially common in the "cheap" market. For example, for SCSI,
> > most of the violations tend to be USB storage - which is supposed to act
> > largely like SCSI, but in reality really doesn't. It locks up if you
> > try to access sectors that aren't there, etc.
>
> Yes .. of course .. but please don't tap some words (without this kind
> comment) which sounds like rules [1]. *Especialy if* talk is about *one*
> specified piece of hardware.
What "one" piece of hardware? There's a hell of a lot more broken USB
devices out there (and no, it's not "one" type either) than there will
probably _ever_ be SAS devices.
And the thing is, from a kernel _maintenance_ standpoint, the broken
hardware is the one that is expensive. Maybe only 0.1% of all hardware
ends up having some bugs - but that doesn't matter. It may look like a
"small" percentage to you, but it ends up being a _huge_ burden on
developers to try to figure out what is going on, often _exactly_ because
it's a small percentage, and the developers don't have it.
So the argument that "most hardware conforms to spec" is not a valid
argument. Not if it's 51%, and not if it's 99.9%. Because the cost is in
the ones that don't.
And that is why I'm trying to educate people that specs are purely paper.
Often much less valuable than a roll of TP.
Because what matters is not the spec, but real life. For example, in the
SCSI layer we've ended up being much more successful with the approach of
trying to use the same discovery sequence as Windows - because unlike the
spec, that's REAL LIFE, and that's the case that actually works.
The same way software inevitably has bugs in areas that haven't been
tested, hardware has bugs in areas that haven't been tested. It has
nothing to do with specs, and no, specs don't make people test it.
Linus
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
