[sane-devel] sane_get_devices and sanei_usb_init

Olaf Meeuwissen olaf.meeuwissen at avasys.jp
Thu Dec 11 23:38:43 UTC 2008


"m. allan noah" <kitno455 at gmail.com> writes:

> On Thu, Dec 11, 2008 at 4:24 PM, ABC <abc at telekom.ru> wrote:
>> On Thu, Dec 11, 2008 at 04:06:24PM -0500, m. allan noah wrote:
>>> On Mon, Dec 1, 2008 at 10:23 PM, ABC <abc at telekom.ru> wrote:
>>> > First of all sanei_usb_init() is not designed to be used for rescanning
>>> > after any other sanei_usb functions is called. It is just initialization
>>> > and rescanning ability is not documented side effect. As stated in
>>> > documentation: "Call this before any other sanei_usb function". So don't
>>> > call it after. (This doesn't state it should be called just once, so we
>>> > could rescan before first device is opened.)
>>>
>>> sanei_usb_init() will blast the existing info, and assign all new
>>> device indexes to whatever it finds.
>>
>> Exactly how it works now.
>>
>>> However, sanei_usb_init() is only
>>> called by backends in sane_init() and sane_get_devices(). A frontend
>>> will only call sane_init() once, so that is not a problem, and the
>>> sane standard says this about sane_get_devices():

Calling sane_init() only once is not a SANE standard requirement.  If
it were, what's the point of sane_exit().

BTW, from the spec of sane_exit():

  [...] After this function returns, no function other than
  sane_init() may be called [...]

>>> The returned list is guaranteed to remain unchanged and valid until
>>> (a) another call to this function is performed or (b) a call to
>>> sane_exit() is performed.
>>
>> This don't says calling sane_get_devices will or should break any
>> already opened device.
>
> That is strongly implied. Why else would it bother to guarantee only
> half of the cycle?

I don't see why, unless the name member explicitly contains the index
used by sanei_usb.  On, at least, GNU/Linux that is not the case.  If
it does anywhere else, I'd consider that a bug.

If sane_get_devices() is allowed to break already opened devices, that
should be explicitly mentioned in the spec.

>>> So, if you call sane_get_devices() twice, you cannot complain that any
>>> devices you have open don't work anymore.
>>
>> I can complain about that, since list of name/vendor/model/type of all
>> available devices is logically not related to any already opened
>> device.
>
> Good point, but not what the standard implies above.

Please reconsider that in light of the above.

>>> However, you have a valid point that most backends only call
>>> sanei_usb_init() in sane_init(), and I think that should change.
>>
>> In backend I'm writing I call sanei_usb_init multiple times (in each
>> sane_get_devices) only if I don't have opened devices. I think that's ok.
>
> Unfortunately, that is not enough. if a person has another brand of
> scanner on their machine, alongside yours, and they open the other
> scanner and then call sane_get_devices(), your backend won't know.
> Then you will blast the list with the other backend's open device in
> it.

Eh, wait.  Aren't backends supposed to link statically with libsanei?
If they do, do they still share sanei_usb.c's

  static device_list_type devices[MAX_DEVICES];

# It still before my first coffee so I can't quite think this one
# through yet.

Hope this helps,
-- 
Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962               Help support software freedom
                 http://www.fsf.org/jf?referrer=1962



More information about the sane-devel mailing list