On 2 Jul, Joerg Schilling wrote:
>>From: [EMAIL PROTECTED]
>
> I am still not sure if would be better not to allow to raise the DMA
> limit in pre-2.4 kernels.
My understanding of the scsi-generic.txt is that a reserved buffer is
indeed available, in which case it would be useful to use
SG_SET_RESERVED_SIZE:
| The size of this reserved buffer can
| subsequently be modified with the SG_SET_RESERVED_SIZE ioctl(). In both
| cases these are requests subject to various dynamic constraints. The actual
| amount of memory obtained can be found by the SG_GET_RESERVED_SIZE ioctl().
| The reserved buffer will be used if:
| - it is not already in use (eg when command queuing is in use)
| - a write() does not call for a buffer size larger than the
| reserved size.
Where did you find that the buffer might not be available later when
actually trying to use it? Neither can a libscg application use command
queuing, nor should it expect to succeed when transmitting more data
than allowed by scsi_maxdma(), so neither of these exceptions applies.
Or does the driver deallocate a buffer although this is not mentioned
in the documentation?
>>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.
Then how do you detect which drives are going to be used? You are right,
I haven't checked the current code well enough to answer this myself.
However, at some point in the past I got the impression that one SCSI
handle may be used to send SCSI commands to all available SCSI drives,
because scsibus/target/lun is not marked as private and used to find the
file descriptor in scsitransp.c:scsicmd() - scsi_scan.c:select_target()
even uses this to find all drives.
>>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.
As far as I can tell the only definition of the function semantics
are the implementations and code that uses them.
I am sure you know exactly what each function does on every platform
and how to use them so that an application works everywhere. I hope you
understand that everyone else can only guess about how to use the
available functions or try to figure it out from the implementation(s),
which is difficult and probably won't result in a complete or correct
picture.
> 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.
Which address restriction are you referring to here? As far as I
understand it the data has to follow the SCSI header and both must be
transfered in one read/write() call, but I don't see why allocating
a buffer to prepend the data with the header dynamically should be
dangerous.
As I told you earlier, simply raising the size of the stack variable
already allowed sending larger chunks, although of course there never
was a guarantee that the DMA buffer for it could be allocated, because
SG_SET_RESERVED_SIZE was not used yet.
Bye, Patrick Ohly
--
[EMAIL PROTECTED] (new permanent address)
[EMAIL PROTECTED] (MakeCD related mails)
http://home.pages.de/~Ohly/
http://makecd.core.de/ (MakeCD home page)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
