Hi Olaf.
I wrote it here with a primary reason to notify developers of other
backends that the problem exist.
simple-scan is quite popular among users, so chances to meet this
problem in wild are not zero.
So if somebody will receive a "simple-scan with your backend crashes my
device" bug report, I hope my posting will save a bit of his or her time.
I'll file, of course, a bug report against simple-scan, but who knows
how long it will take before the bug will be fixed and update will be
widely distributed.
On 8/5/20 2:45 PM, Olaf Meeuwissen wrote:
Hi Alexander,
Alexander Pevzner writes:
Hi everybody,
it can be interesting for many backend developers.
When simple-scan receives SANE_STATUS_DEVICE_BUSY from sane_start(), it
simply retries in a loop. Without any limit, without any delay, simply
spins in retry loop as fast, as backend allows.
This is, in theory, very convenient for users, because as soon as device
becomes ready, scanning resumes automatically.
But it puts device (and backend) under the stress test. And I believe,
not all devices (and not all backends) will survive.
Quoting from the SANE Standard's documentation for sane_start() [1]
> SANE_STATUS_DEVICE_BUSY: The device is busy. The operation should be
retried later.
[1]: https://sane-project.gitlab.io/standard/api.html#sane-start
There is nothing on suggested delays, back-offs or retry counts. I
guess the idea was that API users were well-behaved :-/
Blame simple-scan for not being none of well-behaved, good-neighbourly
and patient. And file a bug report with the appropriate project ;-)
I don't think backends should not be bending over backwards to prevent
frontends from DOS-ing the device. Instead, backend developers should
be cluebatting frontend developers (and vice-versa, btw). They should
not be antagonists. They should work together to build an eco-system
where both have the best interests of the other in mind.
That said, if a DOS attempt has the possibility of causing physical
damage to a device, that is something backend developers should work
hard to prevent.
Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
--
Wishes, Alexander Pevzner ([email protected])
