Charles M. Hannum writes:
> 
> 
>    I've already pointed out that I don't intend this to be a general
>    disk formatting utility.  It is a method of sending arbitrary commands
>    to a SCSI device.
> 
> And I've already pointed out that *I'M NOT TALKING ABOUT A BLOODY
> FORMATTING UTILITY*.  I even gave a specific example of how this could
> screw people, where the user was *CLEARLY* not intending to use it as
> a formatting utility.
> 
> Checking the CDB length will avoid lossage in that specific case, but
> the same caveat applies to mistyping a REQUEST SENSE command, or a
> variety of other trivial mistakes.  The current interface provides no
> way for the user to have any certainty that he/she is not going to
> lose catastrophically.
> 
> Adding mnemonic names for the well-known commands certainly isn't
> difficult, and would go pretty far toward making the interface more
> resistant to errors.  I simply can't fathom why you object so strongly
> to this.

I haven't objected to it yet.

>    There are other users who don't need this level of control.  It is
>    convenient for someone like me to provide scripts for these other
>    users.  I need a basis for this.  The current scsi command provides
>    this basis.
> 
> Nothing I suggested prevents that.
> 
>    If you propose that this capability only be provided within the kernel
>    then I disagree.
> 
> If you think I suggested that, I challenge you to show me where.

Throw down the glove! I thought you must be trying to
provide additional protection, and more than mnemonics as part of
the CDB string.  We already have shells that do a similar thing.

I must be sure to make this explicit: I do not object to making
the program easier to use.

>    The mode page editor provides a clean interface that I consider to be
>    a good interface.  However, I still want the arbitrary interface.
> 
> Nothing I suggested prevents that.
> 
>    However, as you are quick to point out, you intended to be sarcastic
>    and critical.
> 
> I definitely was *not* being `sarcastic'.  Indeed, *your* words -- `so
> that I may learn at the feet of the master' -- are by far the most
> `sarcastic' words I've seen in this thread.

I agree.  An immediate and uncalled for overreaction to your first
input on the matter that included the "careful readers will note that
this interface *sucks*".  I still consider the "careful readers" part
sarcastic. My next follow up by characterized my response as
thin skinned and petulant.

> If you can't deal with someone pointing out a flaw in your program,
> then you have a problem.

If we could come up with a scalar flame measure and do an
analysis of the lists we'll probably discover which of us
has a problem.

The addition of the mode editing feature and a "scsiformat" script
provide a clue that I don't consider the current interface to be
a complete interface.  I've discussed this issue with Joerg Wunsch,
including the discussion of what a command data base could be.  I made
a reference to this discussion on the FreeBSD lists that you monitor.

The lack of a feature doesn't imply the opinion that the feature
is not required.  It is the lack of a feature.  Your characterization
of the current interface as sucky (not inadequate, not
incomplete, but sucky) is what set me off.

Let's start again.  Instead of:

> Careful readers will note that this interface really *sucks*, and it's
> very easy to do something completely different than you intended.

you could have had

> This is a dangerous interface.  How about
> providing something symbolic for those of us who don't know
> every SCSI CDB by heart?

and we could have had a discussion.

I'll give all NetBSD readers a break and retreat to the FreeBSD lists.
I believe this full exchange speaks for itself.

Peter

-- 
Peter Dufault               Real Time Machine Control and Simulation
HD Associates, Inc.         Voice: 508 433 6936
dufault@hda.com             Fax:   508 433 5267