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