On Mon, 24 Jul 2000, Paul Barton-Davis wrote:
>>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.
Hmm.. Well, if the feature is not something common, then it
wouldn't qualify to get put in I suppose. Common features
between many devices should have a common API though.
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate... Our continuing mission: To seek out knowledge of C, to explore strange UNIX commands, and to boldly code where no one has man page 4.
- 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