On Tue, Dec 7, 2010 at 6:04 PM, Olaf Meeuwissen <olaf.meeuwissen at avasys.jp> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2010?12?07? 22:32, m. allan noah wrote: >> On Tue, Dec 7, 2010 at 12:43 AM, Olaf Meeuwissen >> <olaf.meeuwissen at avasys.jp> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 2010-12-07 12:17, m. allan noah wrote: >>>> [...] >>>> 1. Move calls to sanei_usb_init() to sane_get_devices() >>> >>> How does this work when a frontend does not call sane_get_devices() and >>> immediately tries to sane_open() a USB device? >> >> [...] >>> Backends can safely call sanei_usb_init() in both sane_init() and >>> sane_get_devices(). ?They should just move the device discovery logic to >>> sane_get_devices() and call that from sane_init() if they really still >>> want to do discovery at sane_init(). >> >> Actually, since sane_init() calls are usually followed by >> sane_get_devices(), it makes more sense to do this within sane_open() >> if no device name is given or if the list is not already loaded. This >> is the technique I used for the fujitsu backend. > > The problem is with "usually". ?Backend maintainers have no guarantee > from the spec that frontends will do so.
Certainly, but the 'usually' means than most of the time, the backend would search for devices in sane_init, and do it again a millisecond later in sane_get_devices. > > In the epkowa backend I also call sane_get_devices() in sane_open() if > it hasn't been called yet but that's just because I'm too lazy to: > ?- decide what the first available device is in case of no device name > ?- bother with validating the device name properly (it's easier to see > whether it's in the list) If its lazy but it works, it's not lazy :) So, lets consider my original request amended with this later suggestion- watch out for the case of a front-end which does not call sane_get_devices. allan -- "The truth is an offense, but not a sin"
