Messages in this thread | | | From | "Khimenko Victor" <> | Date | Wed, 26 Jul 2000 14:21:35 +0400 (MSD) | Subject | Re: Direct access to hardware |
| |
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/
| |