>From: [EMAIL PROTECTED]
>Thanks for taking the time to improve the Linux support in libscg. I am
>sure many people appreciate this - I am one of them. As you know I have
>had a close look at your source before and I used it in UAE. I also
>looked at the recent changes and have some questions:
>>From the source:
>| #if defined(SG_SET_RESERVED_SIZE) && defined(SG_GET_RESERVED_SIZE)
>| /*
>| * Use the curious new kernel interface found on Linux 2.4.
>| */
>| maxdma = scsi_raisedma(scgp, amt);
>| #endif
>Wasn't this interface already introduced in 2.2.x?
Depends on how you rate the effects...
1) It was not available in 2.2.5
2) The last time I looked at the source before 2.4 came out, there
was a similar interface but it was not usable because you have
been allowed to raise the DMA limit but after that there was no
guarantee that later on the kernel has enough memory to run
requests that use the raised DMA count.
Tht current maintainer of the SG driver decided not discuss things with
me in order to find decent interface definitions.
This unwillingness would have forced me to constantly do code reviews
on the SG driver in order to check if the SG driver turned usable.
I hope that you understand that I have better things to do in my spare time.
When I checked the 2.4 source code, I found that this code will allocate
the needed memory when raising the DMA limit. This make the feature
usable.
I am still not sure if would be better not to allow to raise the DMA
limit in pre-2.4 kernels.
>The new implementation of scsi_maxdma() sets the DMA buffer of all
>available drives. Wouldn't it be better if a libscg application could
>set the buffer of only those drives it really uses, and not of all
drives it has access to?
If you would check my code thoroughly, you would have notived that
this is already the case. scsi_raisedma() only affects drives that
are going to be used.
>Is there a definition of the scsi_maxdma() semantic at all? I'd
>suggest to use scgp->scsibus/target/lun to determine the drive that is
>affected by the call and use -1 as a wildcard to match more than one
>drive.
The expected usage is:
scgp = open_scsi(...)
n = scsi_maxdma(scgp, wanted);
scsi_getbuf(scgp, n);
>The behaviour of scsi_maxdma() for systems that don't support setting
>the buffer for single drives would have to be defined.
It already _is_ defined: pass wanted value and return granted value
Tis definition has not changed since january 1997 and will not need to be
changed.
BTW: _all other_ systems (besides Linux) do not allow to raise the limit.
>On 1 Jul, Joerg Schilling wrote:
>> - libscg now handles a problem hat arises on Linux-2.2.10 ??? and newer
>> (newer releases before Linux-2.4) where it is already possible to
>> raise the DMA limit for the sg driver but there is no SCSI ioctl command.
>Remember that I told you that the fixed size of your
> struct sg_rq {
> struct sg_header hd;
> unsigned char buf[MAX_DMA_LINUX+SCG_MAX_CMD];
> } sg_rq;
>was the major obstacle that prevented larger transfer sizes in the
>libscg of cdrecord 1.8.1? You seem to agree now... ;-)
NO. The current implementation is not clean.
It may be that I will have to forbid raisedma() for pre-2.4 kernels
if it turnes out that raising the dma limit is only safe with 2.4
kernels. In this case, I will remove the current hacky code and revert
to the safe implementation that uses the stack variable only.
This is possible as the 2.4 kernels introduce an ioctl() implementation
that does not have limitations on the DMA address anymore.
It is not needed to copy data in user space anymore and there is no need
for a copy buffer of sufficient size.
J�rg
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
