On Wed, 12 Jun 1996 15:24:08 -0400 
 "Michael Graff" <explorer@flame.org> wrote:

 > Jason has been very good in the volunteer department.  I'd not be
 > surprised if he did do the work.

I did some preliminary work on this, which was subsequently eaten by a 
disk crash :-/

Basically, I had functions like:

scsicmd_test_unit_ready()
scsicmd_inquiry()
scsicmd_mode_sense()

etc.

None of the SCSI internals were exported to to the caller .. it was by no 
means complete... it was a spare time hack that I'd been toying with.

Now, I could possibly see some value in a FreeBSD libscsi-like interface 
(i.e. one that can parse a simple grammar and build the cdb's, decode 
sense data, and whatnot) _combined_ with a clean abstraction layer.  I 
acknowledge that an API for sending raw SCSI commands would be nice (and 
we have one .. it's just not terribly _refined_ :-) ... however, 
personally, I wouldn't take the FreeBSD interface as-is... I would modify 
it a bit.

Specifically:

     struct scsireq *
     scsireq_new(void)

     struct scsireq *
     scsireq_reset(struct scsireq *)

     int
     SCSIREQ_ERROR(struct scsireq *)

If you look at scsireq_new(), all it does is malloc() a new scsireq_t and 
call scsireq_reset() with it...scsireq_reset() basically just bzero's the 
structure and sets an initial timeout of 2 seconds.  I'm not sure I see 
the value in having both of those routines present, since the internals 
of the scsireq structure are exposed to the caller, anyhow.

Also, I don't particularly like the definition of SCSIREQ_ERROR().  
Firstly, it's the only routine in the API with an annoyingly all-caps 
name (but that's a nit).  Secondly, I personally would prefer it to be 
more like kvm_geterr() ... i.e. you pass it a scsireq_t *, and it returns 
an appropriate error _string_, suitable for printing.

There are some other things, too ... but, I've got a zillion other things 
I have to do at the moment, and don't have time to a) remember them all, 
b) find the notepad where I scribbled all of this down in the first 
place.

Anyhow, some more of my thoughts on the subject ... may they go in the 
list archives so that someone might turn them into something useful 
someday :-)

----save the ancient forests - http://www.bayarea.net/~thorpej/forest/----
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939