My point, to be made, is the need for some method of disabling drives
and hardware that are questionable. This will allow the code to be
completely checked out. Then we can attemp to find work arounds for
the non-standard behaviors.
The strategy of using blacklists work as long as the number of bogus
hardware devices is small, and well-defined. If it's random (i.e.,
depends on the cable length, or what hardware integrator put together
the machine, etc.), then sometimes the only thing we can do is disable
the performance hacks by default, and make the user manually turn on the
performance enhancements. (And make sure that switches, and warnings,
are well documented.)
Remember --- we're writing an OS for commodity hardware. There's a lot
of sh*t out there. When I wrote the serial driver, I had to put in all
sorts of paranoia and checks, because even if it wasn't my fault, the
people with the bogus hardware would send me the hate-mail.
Andy Grove's favorite saying about "only the paranoid" survive is doubly
true when writing drivers for PC-class hardware. Just remember that
there's a lot of garbage out there for which people paid good money.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html