>From: Douglas Gilbert <[EMAIL PROTECTED]>

>[EMAIL PROTECTED] wrote:
>> 
>> >From [EMAIL PROTECTED] Mon Jul  3 16:56:45 2000
>> [snip]
>> 
>> It seems that you did not understand how interfaces in a POSIX enviroment
>> are implemented:
>> 
>> -       Call syscall of ioctl() function with parameters
>> 
>> -       Check return value
>> 
>> -       If return value >= 0, operation worked as expected
>> 
>> -       If return value == -1, operation did not work
>> 
>> >From this POSIX point of view,  SG_SET_RESERVED_SIZE is not even
>> working correctly for the Linux 2.4 implementaion. It always returns
>> success regardless of what happens on behalf of it's execution.

>It depends on how you define "worked as expected". It returns success
>in the case where 512 KB (for example) is requested and 256 KB is 
>obtained. There is a strong hint here: that's the best you going to 
>get at the moment. Could that information be conveyed with an error
>message? Perhaps cdrecord would like to do a binary chop to find out
>the biggest reserved buffer in can obtain before deciding whether that
>is of sufficient size. As for the "always returns success": the 
>reserved buffer can be in use in which case the ioctl yields EBUSY. 
>See the sg documentation.

>Even when you don't wish to call SG_SET_RESERVED_SIZE then an
>application like cdrecord still should call SG_GET_RESERVED_SIZE
>after an open() because there is no guarantee that the default
>sized 32 KB reserve buffer was obtained either. 

It does...

But it is really a bad idea to waste limited resources as it is done
with the current version of the sg driver.

The current implementation needs to allocate a buffer per driver
instance.

If memory is rare, it would make more sense to pool the buffers.
Solaris e.g. pools all DMA resources of the whole system.
If the OS (in this case Linux) does not support a centralised 
DMA buffer pool, then it could help to pool the buffers in a driver.

If we get to the real limit, then on Linux we get ENOMEM.
On Solaris, the current transfer is delayed for a short time
until a buffer is available from the global pool. As cdrecod on 
Solaris runs on a priotity that is even higher than the pager
daemon in the kernel, cdrecord will also get the highes priority
while wayting for a buffer from the central DMA pool. 

I am writing this as it seems that you don't have access to other
OS source code and for this reason cannot compare different 
implementaions.
k
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]



Reply via email to