> > 1. It would be fine to have the buffer size user
> > configurable. This could be done either with a configuration
> > file, or with an environment variable.
>
> You mean how much space it should try to reserve ?
>
> IMHO we should enhance the sanei_scsi API to be able to negotiate that
> at sanei_scsi_open()-time. That would kill off your problem #2 as well.
>
> I would suggest to add something along the lines of a , int *maxsize);
> which would be filled with the desired size at call time and with the
> guaranteed minimum size when it returns. That does away with that ugly
> global variable sanei_scsi_max_request_size.
>
> For compatibility with existing backends, we could keep the global
> variable with the minimum value ever obtained and wrap the new call
> up like:
>
> sanei_scsi_open (const char *dev, int *fdp,
> SANEI_SCSI_Sense_Handler handler, void *handler_arg)
> {
> return sanei_scsi_open_extended (dev, fdp, handler, handler_arg,
> &sanei_scsi_max_request_size);
> }
>
> This of course requires, that sanei_scsi_max_request_size is set small
> enough at startup to avoid problems with backends that make assumptions
> about it even _before_ calling sanei_scsi_open();.
A problem with this implementation is that several backends - including
the one for Sharp scanners written by Kazuya and me - rely on a value of
sanei_scsi_max_request_size which is constant, after a device is opened.
Thus, your "wrapper function" might confuse these backends, if the
frontend attaches to a second device. As said in my first mail, this is
right now only a theoretical situation, since all existing frontends
open only one device.
These problems could be avoided if sanei_scsi_open makes sure that not
more than one device can be opened in parallel, while
sanei_scsi_open_extended would allow to open more then one device.
> A thing I miss with your patch - oh stop - I see it was corrected in
> 1.0.1. already (I'm talking about the static buffer allocation with
> size SG_BIG_BUFF in SANE 1.0.0 that caused very weird problems for me).
> Great.
>
> > + ioctl_val = 128 * 1024;
>
> Yep. I'd like to see that configureable. I'd do it inside the backend,
> which might e.g. know, the scanner can't handle >64k anyway and thus it can
> choose not to waste ressources. Most backends parse options anyway, so
> another "buffersize=256k" option won't cause much grief.
I agree. (And I must admit that I use 256k buffer size on my Linux box:
The Sharp JX-250 is under certain conditions much more faster with this
buffer size.)
> > + ioctl(fd, SG_SET_RESERVED_SIZE, &ioctl_val);
> > + if (0 == ioctl(fd, SG_GET_RESERVED_SIZE, &ioctl_val))
> > + sanei_scsi_max_request_size = ioctl_val;
>
> What exactly happens when the set fails ? Downgrade to maximum possible
> value, or keep default ?
Don't ask me -- the idea of the get call is to retrieve the actual
buffer size. We should ask Douglas for the exact behaviour. (BTW, it
seems that an "else" for the "get" call is missing: if it fails,
sanei_scsi_open should return an error.)
> Other than that, I really like your patch. Looks very promising. Pity I
> can't test ist too soon. But definitely at the next servicing interval
> of the server that has the scanner.
>
> I'd say we should collect some test data from a few people, and apply it
> for now, if it works well.
I forgot to mention another (right now theoretical) problem of my
modification regading command queueing: As the recently fixed problem of
the Agfa backend with the new SG driver showed, it is possible that two
processes (practically, a reader process and its parent) access the
scanner simultaneously. While Kevin removed this "double access" in the
Agfa backend, there was obviously up to now no need to forbid this type
of parallel access. If the "low level command queueing" is used, a
similar problem is reintroduced with the low level command queueing,
which can lead to a race condition between the reader process and its
parent, if the reader process fill the command queue completely with
"read data" command, and the parent process tries to retireve some
status information from the scanner.
While a short look into the backends shows that none of them seems to
have this problem, my modifications to sanei_scsi_req_enter /
sanei_scsi_req_wait definitely introduce a specific restriction which
should be discussed.
Perhaps we should take both the "more specific" behaviour of the command
queueing and the problems with sanei_scsi_open and
sanei_max_scsi_request_size as an occasion to think over sanei_scsi.c
more generally: May be that the people taking care of the implemetaion
for other operating systems have some comments too.
Abel
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com