[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.021 / U:35.740 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site