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