[lkml]   [2000]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Direct access to hardware
In <> James Sutherland ( 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.051 / U:0.944 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site