In <Pine.LNX.4.10.10007252126510.15969-100000@dax.joh.cam.ac.uk> James Sutherland (jas88@cam.ac.uk) wrote:
> 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**.
This is not THAT simple. Not the whole world is hard drives. Especially
with SCSI world.
> 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'?
And if I need C comiler I hardly want to add switch --cc to ls - better to
invent gcc :-)
> 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.
What about new command to change resolution in scanner ?
> That way, all you ever need is the latest ATA-* driver.
Which in turn will include knowleadge about scanners and photo-cameras.
No, thnx.
> 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!
-
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:21 EST