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
