[sane-devel] Proposal to change function signatures of a couple of sanei_usb_* functions

[Ralph Little]

Hi,

On 2022-08-06 12:04, Olivier Valentin wrote:
>
>
>>> I propose that we change the function signature of the functions and the callback to include a (void *) context pointer:
>>>
>>> SANE_Status
>>> sanei_usb_find_devices (SANE_Int vendor, SANE_Int product, void *context,
>>>              SANE_Status (*attach) (SANE_String_Const dev, void *context));
>>>
>>> void
>>> sanei_usb_attach_matching_devices (const char *name, void *context,
>>>                     SANE_Status (*attach) (const char *dev, void *context));
>>>
>> Hi Ralph,
>>
>> Your change may impact proprietary backends (Brother, Canon, ...).
>>
>> Thierry
>>
> Would it be possible to rely on the relative position of `const char *dev` inside the device structure by making use of `container_of()` ?
>
> Olivier

The name that is provided comes from a private structure in the sanei*() 
library and so I don't think that the wider structure it is really 
accessible to the backend.
In this situation, my backend is iterating through a list of predefined, 
supported scanners, each with USB vendor and product values. If a match 
is found, the callback is triggered, but the backend doesn't have any 
context to determine which of the supported scanner structures it 
relates to. In my case, all of the useful information is in there and 
the new device structure that the callback creates needs to have a 
pointer to that original structure.

What I am doing now, is using the USB vendor and product values that I 
can get from sanei_usb_get_vendor_product_byname() to search again 
through the list of supported scanners to get it back again.
Other backends typically stick that pointer into a global variable for 
the callback function to refer to.

I prefer the first because I instinctively feel that using globals to 
pass context information to the callback feels sucky, although of course 
the callback is also creating a new device structure and adding it to a 
global list. That's not really avoidable but for some reason it doesn't 
feel as hacky as the global context variable.

For the moment, I will stick with one of the regular solutions.

Cheers,
Ralph