[sane-devel] RFC: proposal for an improved sanei_scsi library
Sun, 8 Dec 2002 16:52:53 +0100
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
> 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
> >>* @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
> >>* 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".