kopia lustrzana https://gitlab.com/sane-project/website
174 wiersze
6.7 KiB
HTML
174 wiersze
6.7 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
|
|
"http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>sane-devel: Re: reaction to a smaller buffer size</TITLE>
|
|
<META NAME="Author" CONTENT="abel deuring (a.deuring@satzbau-gmbh.de)">
|
|
<META NAME="Subject" CONTENT="Re: reaction to a smaller buffer size">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
|
|
<H1>Re: reaction to a smaller buffer size</H1>
|
|
<!-- received="Sun Nov 19 10:25:41 2000" -->
|
|
<!-- isoreceived="20001119182541" -->
|
|
<!-- sent="Sun, 19 Nov 2000 20:49:04 +0100" -->
|
|
<!-- isosent="20001119194904" -->
|
|
<!-- name="abel deuring" -->
|
|
<!-- email="a.deuring@satzbau-gmbh.de" -->
|
|
<!-- subject="Re: reaction to a smaller buffer size" -->
|
|
<!-- id="3A182EB0.422149CB@satzbau-gmbh.de" -->
|
|
<!-- inreplyto="00111919071000.00396@ghanima" -->
|
|
<STRONG>From:</STRONG> abel deuring (<A HREF="mailto:a.deuring@satzbau-gmbh.de?Subject=Re:%20reaction%20to%20a%20smaller%20buffer%20size&In-Reply-To=<3A182EB0.422149CB@satzbau-gmbh.de>"><EM>a.deuring@satzbau-gmbh.de</EM></A>)<BR>
|
|
<STRONG>Date:</STRONG> Sun Nov 19 2000 - 11:49:04 PST
|
|
<P>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0257.html">Henning Meier-Geinitz: "Re: Excessive Warnings from CVS build"</A>
|
|
<UL>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0255.html">Oliver Neukum: "Re: reaction to a smaller buffer size"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0255.html">Oliver Neukum: "Re: reaction to a smaller buffer size"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0258.html">Oliver Neukum: "Re: reaction to a smaller buffer size"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0258.html">Oliver Neukum: "Re: reaction to a smaller buffer size"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#256">[ date ]</A>
|
|
<A HREF="index.html#256">[ thread ]</A>
|
|
<A HREF="subject.html#256">[ subject ]</A>
|
|
<A HREF="author.html#256">[ author ]</A>
|
|
</UL>
|
|
<HR NOSHADE><P>
|
|
<!-- body="start" -->
|
|
<P>
|
|
Oliver Neukum wrote:
|
|
<BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> > The problem is that a backend may consider sanei_scsi_max_request_size
|
|
</EM><BR>
|
|
<EM>> > as a constant. This was true for the old Linux SG driver; but with the
|
|
</EM><BR>
|
|
<EM>> > new SG driver it is at least in theory possible that you get different
|
|
</EM><BR>
|
|
<EM>> > buffer sizes each time a SG device file is opened. (Not very likely, but
|
|
</EM><BR>
|
|
<EM>> > it is possible)
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> It's virtually certain if you have two host adapters, whose drivers differ
|
|
</EM><BR>
|
|
<EM>> in their ability to do scatter/gather. This means that SANE will always
|
|
</EM><BR>
|
|
<EM>> fail in that setup.
|
|
</EM><BR>
|
|
<P>Oliver,
|
|
<BR>
|
|
<P>agreed, it is really not likely that we get different amount of memory
|
|
<BR>
|
|
after different open calls. But exactly this can be a problem: Imagine a
|
|
<BR>
|
|
Sane user working on an ooverloaded Linux box, who gets from time to
|
|
<BR>
|
|
time segfaults, and that [s]he can't reproduce this behaviuor reliably.
|
|
<BR>
|
|
How someone get the idea that this behaviour might be caused by a
|
|
<BR>
|
|
changing sanei_scsi_max_request_size?
|
|
<BR>
|
|
<P><EM>> > Both situations might have caused unnecessary work and headaches for
|
|
</EM><BR>
|
|
<EM>> > backend developers, who don't need or don't want to switch to
|
|
</EM><BR>
|
|
<EM>> > sanei_scsi_open_extended, and therefore I decided to use this "paranoid"
|
|
</EM><BR>
|
|
<EM>> > looking "if (real_buffersize != wanted_buffersize)", when I introduced
|
|
</EM><BR>
|
|
<EM>> > sane_scsi_open_extended and related stuff.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> I see, but in the case I mentioned above the user needs to limit the
|
|
</EM><BR>
|
|
<EM>> buffer by setting enviromental variables.
|
|
</EM><BR>
|
|
<P>I remember. Another option would be to use the configure option
|
|
<BR>
|
|
--enable-scsibuffersize. but of course this does not help either, if
|
|
<BR>
|
|
someone is using a standard RPM.
|
|
<BR>
|
|
<P><EM>>
|
|
</EM><BR>
|
|
<EM>> > > Why don't you use sanei_scsi_open_extended if it is available for your
|
|
</EM><BR>
|
|
<EM>> > > paltform? In this case the backend can try to get a big buffer and
|
|
</EM><BR>
|
|
<EM>> > > knows the actual size it is allowed to use.
|
|
</EM><BR>
|
|
<EM>>
|
|
</EM><BR>
|
|
<EM>> I am using an existing backend (microtek2). It works with this check removed.
|
|
</EM><BR>
|
|
<EM>> Is converting a backend to use sanei_scsi_open_extended difficult ?
|
|
</EM><BR>
|
|
<P>The main task is to get rid of sanei_scsi_max_request_size; replace it
|
|
<BR>
|
|
with something like s->maxbuffersize, and make sure that the backend is
|
|
<BR>
|
|
really aware of a changing buffer size. When I changed the Sharp backend
|
|
<BR>
|
|
to use sanei_scsi_open_extended, I replaced sanei_scsi_max_request_size
|
|
<BR>
|
|
with xxxsanei_scsi_max_request_size, looked at every line causing a
|
|
<BR>
|
|
compiler error, and checked, how sanei_scsi_max_request_size is/was
|
|
<BR>
|
|
used: largest number of scan lines to be read with one SCSI command,
|
|
<BR>
|
|
malloc() and so on. Next, you need to know, where close(devicefile) and
|
|
<BR>
|
|
open(devicefile) are called, so that you can be sure that you won't have
|
|
<BR>
|
|
close/open cycle e.g. between a malloc call and the usage of this
|
|
<BR>
|
|
buffer.
|
|
<BR>
|
|
<P>For a test, you can deliberately change the buffer size for the open
|
|
<BR>
|
|
call of consecutive scans.
|
|
<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?Subject=Re:%20reaction%20to%20a%20smaller%20buffer%20size&In-Reply-To=<3A182EB0.422149CB@satzbau-gmbh.de>">majordomo@mostang.com</A>
|
|
</PRE>
|
|
<P><!-- body="end" -->
|
|
<HR NOSHADE>
|
|
<UL>
|
|
<!-- next="start" -->
|
|
<LI><STRONG>Next message:</STRONG> <A HREF="0257.html">Henning Meier-Geinitz: "Re: Excessive Warnings from CVS build"</A>
|
|
<LI><STRONG>Previous message:</STRONG> <A HREF="0255.html">Oliver Neukum: "Re: reaction to a smaller buffer size"</A>
|
|
<LI><STRONG>In reply to:</STRONG> <A HREF="0255.html">Oliver Neukum: "Re: reaction to a smaller buffer size"</A>
|
|
<!-- nextthread="start" -->
|
|
<LI><STRONG>Next in thread:</STRONG> <A HREF="0258.html">Oliver Neukum: "Re: reaction to a smaller buffer size"</A>
|
|
<LI><STRONG>Reply:</STRONG> <A HREF="0258.html">Oliver Neukum: "Re: reaction to a smaller buffer size"</A>
|
|
<!-- reply="end" -->
|
|
<LI><STRONG>Messages sorted by:</STRONG>
|
|
<A HREF="date.html#256">[ date ]</A>
|
|
<A HREF="index.html#256">[ thread ]</A>
|
|
<A HREF="subject.html#256">[ subject ]</A>
|
|
<A HREF="author.html#256">[ author ]</A>
|
|
</UL>
|
|
<!-- trailer="footer" -->
|
|
<HR NOSHADE>
|
|
<P>
|
|
<SMALL>
|
|
<EM>
|
|
This archive was generated by <A HREF="http://www.hypermail.org/">hypermail 2b29</A>
|
|
: <EM>Sun Nov 19 2000 - 10:28:11 PST</EM>
|
|
</EM>
|
|
</SMALL>
|
|
</BODY>
|
|
</HTML>
|