>Thats right. I agree with that completely. You put a layer of
>abstraction in so FEATURE_1 maps to vendor 1's proprietary
>command for feature 1, and FEATURE_1 maps to vendor 2's
>proprietary and different command, etc..
>
>1 driver that supports multiple hardware. NOT multiple drivers.
And so what do you do when there is a FEATURE for a device that
communicates via a standard protocol that doesn't map onto the
existing FEATURE set ? Simply say "sorry, you'll need a new kernel
module for that (even though we know you used to be able to just send
a generic SCSI message) ?" Or do you go for code bloat, and now
require all low level disk interfaces to support, for example,
password-controlled write-protection (the Jaz drives have this, for
example) ? This looks suspiciously like the Idiot's Veto, in that any
FEATURE present on any device has to implemented (even if just with a
stub) by all.
--p
-
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.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:16 EST