[EMAIL PROTECTED] 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.
>
> >From reading the source:
>
> case SG_SET_RESERVED_SIZE:
> /* currently ignored, future extension */
> if (O_RDWR != (filp->f_flags & O_ACCMODE))
> return -EACCES;
> result = verify_area(VERIFY_READ, (const void *)arg, sizeof(int));
> if (result) return result;
> return 0;
> case SG_GET_RESERVED_SIZE:
> result = verify_area(VERIFY_WRITE, (void *) arg, sizeof(int));
> if (result) return result;
> put_user(sfp->fb_size, (int *)arg);
> return 0;
>
> As you see the March 99 version if sg.c implemented SG_SET_RESERVED_SIZE as NO-OP.
>
> For this reason, I mailed to the maintainer but he was either unwilling or unable
> to understand that this is unreliable code which I cannot support.
For a start, _not_ implementing SG_SET_RESERVED_SIZE fits in
with the protocol of calling the "SET" with the size that
you want followed by the "GET" to see if you got it.
