sane-project-website/old-archive/1999-08/0285.html

<!-- received="Mon Aug 23 14:42:07 1999 PDT" -->
<!-- sent="Mon, 23 Aug 1999 23:47:23 +0200" -->
<!-- name="Andreas Beck" -->
<!-- email="becka@rz.uni-duesseldorf.de" -->
<!-- subject="Re: SG_BIG_BUFF, glibc 2.1 weirdness ..." -->
<!-- id="" -->
<!-- inreplyto="37C05316.8306825E@satzbau-gmbh.de" -->
<title>sane-devel: Re: SG_BIG_BUFF, glibc 2.1 weirdness ...</title>
<h1>Re: SG_BIG_BUFF, glibc 2.1 weirdness ...</h1>
<b>Andreas Beck</b> (<a href="mailto:becka@rz.uni-duesseldorf.de"><i>becka@rz.uni-duesseldorf.de</i></a>)<br>
<i>Mon, 23 Aug 1999 23:47:23 +0200</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#285">[ date ]</a><a href="index.html#285">[ thread ]</a><a href="subject.html#285">[ subject ]</a><a href="author.html#285">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0286.html">Andreas Beck: "Re: SANE V2"</a>
<li> <b>Previous message:</b> <a href="0284.html">Nick Lamb: "Re: SANE V2"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>
<!-- body="start" -->
Hi Abel !<br>
<p>
<i>&gt; &gt; I'll take care for a graceful handling of the condition as well as support</i><br>
<i>&gt; &gt; for the new sg driver in 2.2.6 and up.</i><br>
<p>
<i>&gt; Sorry for the delay with my response to Andreas' mail, but I was </i><br>
<i>&gt; on holidays the last weeks.</i><br>
<p>
No problem. Fortunately I was very busy, so no double work done yet.<br>
<p>
<i>&gt; I have already made some work on the support for the new Linux </i><br>
<i>&gt; SG driver in sanei_scsi.c, in order to use the capabilites of </i><br>
<i>&gt; this driver to change its buffer size dynamically, and to enable </i><br>
<i>&gt; low level command queueing.</i><br>
<p>
Great. Very good. Your code below looks good as well, especially, as you<br>
already talked to Douglas to avoid any misconceptions and stuff.<br>
<p>
<i>&gt; Two details of the modifications would need an improvement:</i><br>
<p>
<i>&gt; 1. It would be fine to have the buffer size user</i><br>
<i>&gt; configurable. This could be done either with a configuration</i><br>
<i>&gt; file, or with an environment variable.</i><br>
<p>
You mean how much space it should try to reserve ?<br>
<p>
IMHO we should enhance the sanei_scsi API to be able to negotiate that<br>
at sanei_scsi_open()-time. That would kill off your problem #2 as well.<br>
<p>
I would suggest to add something along the lines of a , int *maxsize);<br>
which would be filled with the desired size at call time and with the<br>
guaranteed minimum size when it returns. That does away with that ugly<br>
global variable sanei_scsi_max_request_size.<br>
<p>
For compatibility with existing backends, we could keep the global <br>
variable with the minimum value ever obtained and wrap the new call <br>
up like:<br>
<p>
sanei_scsi_open (const char *dev, int *fdp,<br>
                 SANEI_SCSI_Sense_Handler handler, void *handler_arg)<br>
{<br>
	return sanei_scsi_open_extended (dev, fdp, handler, handler_arg,<br>
			&amp;sanei_scsi_max_request_size);<br>
}<br>
<p>
This of course requires, that sanei_scsi_max_request_size is set small<br>
enough at startup to avoid problems with backends that make assumptions<br>
about it even _before_ calling sanei_scsi_open();.<br>
<p>
<i>&gt; 2. The new SG driver allocates a separate buffer for each</i><br>
<i>&gt; file handle. This means, that a situation is possible, where</i><br>
<i>&gt; the ioctl call to modify the buffer size is successful for</i><br>
<i>&gt; one file handle, but it fails for another. </i><br>
<p>
Yes. The above modification would cover that - right ?<br>
<p>
<i>&gt; this inconsistency for now. It should of course be fixed, if</i><br>
<i>&gt; these patches will be accepted.</i><br>
<p>
Yep.<br>
<p>
A thing I miss with your patch - oh stop - I see it was corrected in<br>
1.0.1. already (I'm talking about the static buffer allocation with<br>
size SG_BIG_BUFF in SANE 1.0.0 that caused very weird problems for me). <br>
Great.<br>
<p>
<i>&gt; +        ioctl_val = 128 * 1024;</i><br>
<p>
Yep. I'd like to see that configureable. I'd do it inside the backend,<br>
which might e.g. know, the scanner can't handle &gt;64k anyway and thus it can<br>
choose not to waste ressources. Most backends parse options anyway, so<br>
another "buffersize=256k" option won't cause much grief.<br>
<p>
<i>&gt; +        ioctl(fd, SG_SET_RESERVED_SIZE, &amp;ioctl_val);</i><br>
<i>&gt; +        if (0 == ioctl(fd, SG_GET_RESERVED_SIZE, &amp;ioctl_val)) </i><br>
<i>&gt; +          sanei_scsi_max_request_size = ioctl_val;</i><br>
<p>
What exactly happens when the set fails ? Downgrade to maximum possible<br>
value, or keep default ?<br>
<p>
We should try to get the former, eventually using a loop.<br>
<p>
Other than that, I really like your patch. Looks very promising. Pity I<br>
can't test ist too soon. But definitely at the next servicing interval <br>
of the server that has the scanner.<br>
<p>
I'd say we should collect some test data from a few people, and apply it <br>
for now, if it works well.<br>
<p>
CU, Andy<br>
<p>
<pre>
-- 
= Andreas Beck                    |  Email :  &lt;<a href="mailto:andreas.beck@ggi-project.org">andreas.beck@ggi-project.org</a>&gt; =
<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="0286.html">Andreas Beck: "Re: SANE V2"</a>
<li> <b>Previous message:</b> <a href="0284.html">Nick Lamb: "Re: SANE V2"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>