Subject: Re: BAD BLOCKS WITH SCSI DISKS, HOW TO REMAP
To: None <thorpej@nas.nasa.gov>
From: Peter Dufault <dufault@hda>
List: current-users
Date: 06/13/1996 06:52:11
> 
> 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.

There is a need for the layer discussed as soon as someone finds
themselves writing more than one program that uses the library.
If there are several programs similar to "cdplay" using it it is
needed; if there are a few programs doing things like formatting
disks and reallocating blocks it isn't needed since these can be
pulled into a single utility.

I have a predecessor library that ran on Suns, HPs, 386bsd and Sony
News systems.  It is layered on top of the equivalent of the
scsireq_t, and the contents of the data structure aren't exported
out of the library.

The reason that this interface isn't in the current libscsi is
because I was interested in building "scsi -c" and pushing things
up into a table driven utility and not a library.  I wanted to see
if the abstracted interface could be at the table and program
interface instead of a library interface.

The scsi mode page editor in "scsi(8)" is a first piece of this:
a user can edit a mode page in the ASCII description file using
their customary editor.

If I were to do any more work on user mode scsi the next piece
would still not be that library interface but instead a command
lookup data base to support:

"scsi sd0 format" or
"scsi sd0 realloc 0x3244"

as this would lessen the need for special little programs.

For the record for any library implementer, in practice I
had used these in the old library:

gs_test_unit_ready
gs_inquiry
gs_initialize_element_status
gs_format_unit
gs_mode_sense
gs_mode_select
gs_log_sense
gs_send
gs_receive

There are additional packaged up functions in specific device
support source for non-standard devices (Canon and Microtek scanner,
frame grabber, Optronics plotter).  None of these use many standard
SCSI cdbs - this contributed to the decision to do "scsi -c" first:
"scsi -c" was the hard work that would have made doing the abstracted
interface for screwy devices a lot easier.

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