On Tue, 25 Jul 2000, Paul Barton-Davis wrote:
> >> let me get this straight. are you saying that the "jaz" utility which
> >> lets me password-protect write access to my jaz disks should not exist
> >> under Linux ? this utility requires the ability to send that are
> >> vendor-and-device-specific SCSI commands to the drive.
> >
> >That doesn't sound like a good implementation, but I doubt these commands
> >would be in the same category of command as the flash update ones. I'm
> >interested in the dangerous category, not the merely undocumented bits.
>
> so, what do you think would be a good implementation and how do you
> propose to distinguish this "category" of command from one to update
> the drive ROM ?
A properly designed protocol would have had support for this sort of
extension to existing facilities, without inventing whole new dialects.
In this case, probably the lock & unlock commands for removable media -
just add a "password" field - **and include this in the standard so no
other vendor uses the same field for something else, or vice versa**.
If I wanted to add a new listing mode to `ls' for some reason, should I
add a new switch to ls's vocabulary, or invent `newls'?
Alternatively, if I really needed a new command for my new feature - drill
holes in disk, say - I get it included in the next revision of the
standard. That way, all you ever need is the latest ATA-* driver.
In short, don't embrace and extend the standard with proprietary things.
If you need a new feature in the standard, put it in the fscking standard
- don't write your own!
James.
-
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:20 EST