Subject: Re: Trouble with PCI, VGA, 32Mbyte
To: Charles M. Hannum <email@example.com>
From: Peter Dufault <firstname.lastname@example.org>
Date: 06/11/1995 07:04:53
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 Dufault Real Time Machine Control and Simulation
HD Associates, Inc. Voice: 508 433 6936
email@example.com Fax: 508 433 5267