[sane-devel] RFC: proposal for an improved sanei_scsi library

[Henning Meier-Geinitz]

Hi,

On Sun, Dec 08, 2002 at 04:15:56PM +0100, abel deuring wrote:
> >I would just switch to the new API in SANE2 and use e.g.
> >sanei_scsi_open (not sanei2_). All backends must be rewritten anyway.
> >So you avoid confusion if it's necessary to add a sanei_scsi_open2 in
> >future.
> 
> Well, there is indeed not urgent need to change the interface for Sane1. 
> But there were a few situations where I wished I had a somewhat cleaner 
> interface at hand for Sane 1 ;) And it would not be difficult to write a 
> compatibility layer for the current interface. But if Sane2 development 
> is taking off soon, work on Sane1 would of course be useless.

I hope It won't take too long to finish the core points of SANE2.

> A SCSI device returns a status byte for every command, giving coarse 
> information about the result of the command (GOOD/CHECK 
> CONDITION/CONDITION MET/BUSY etc). A detailed description can be found 
> in the SCSI2 draft, ftp://ftp.t10.org/t10/drafts/s2/s2-r10l.pdf , 
> section 7.3. The SCSI reference manuals for the scanners should describe 
> it too.

SCSI reference manual for a scanner? Haha. Never seen such a beast.
Either it's labeled "top secret" or it's written in Chinese. At least
for "my" backends. :-)

> >The SANE sttandard requires, that backends can open several devices
> >simultaneously. So I think it is important. And even if there is no
> >frontend yet that supports opening multiple devices it wouldn't be
> >that unusual to just keep the device selection window open to select
> >more scanners.
> 
> Seems that I should re-read the Sane 2 drafts ;)

That's in SANE 1, too: http://www.mostang.com/sane/html/doc013.html#s4.4
Third paragraph.

> >>* @param id id used in sanei2_scsi_req_enter()
> >>* @param sb pointer to a SANE_Byte array, where the SCSI sense data may be
> >>*           stored. The caller must allocate the necessary memory.
> >>*	     The parameter may be NULL.
> >
> >
> >Why is SANE_Byte used here while all the other types are non-SANE
> >types? If you want to make sure that it's a byte (as in 8 bits)
> >buffer, maybe it's better to use u_int8_t or something like that.
> >SANE_Byte must be able to hold 8 bits, but it may be bigger than that.
> 
> Good question ;) Well, we could also simply use an int.

For the status value, yes, but not for sb, as this is a buffer. All
the other buffer pointers use void*. 


> >>* @param scsi_status the status returned by the device. 
> >>*           xxx what about the situation, that the command has not been
> >>*           issued, or other situations, where no status information
> >>*           is available? Can this situation be detected for all supported
> >>*           OSes? If that is possible, we should add another parameter 
> >>which
> >>*	     signals "SCSI status available"
> >
> >
> >Maybe use the return value to flag this. I.e. i/o error: scsi_status
> >has some meaning, invalid arg: something different went wrong.
> 
> I don't like to put more semantics into the return status, But we could 
> add another int* parameter which signals, if *scsi_status contains a 
> valid value.

Or use an int instead of a byte. -1 is "not applicable".

Bye,
  Henning