>From: [EMAIL PROTECTED]
>> As you see the March 99 version if sg.c implemented SG_SET_RESERVED_SIZE as NO-OP.
>I don't know which sg version this file corresponds to. I only have the
I told you: the march 99 version!
>> 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.
>Well, it was changed later. I don't know enough about the history, but
>the comment quoted above makes me think that this change was already
>planed in advance.
It makes no sense to pushlish such important interfaces before you can really
use them. If you decide to add a new interface you have to think about
possible migration consequences. It it is possible to have a have way ready
interface without binary interface problems, you may publish it. If not,
keep it secret.
>> He believed that it would be perfect to hope that the driver will be able to
>> allocate memory when it is needed. His intension was to define an interface
>> that works like: "Trust me, just walk throu the wall - it will work".
>>
>> While this works perfectly for stepping into automounted directories,
>> it will not work for the sg driver as the "space behind the wall" would have to
>> be allocated from a limited resource - just in time.
>Please forgive me for commenting on a conversation that I know nothing
>about, but to me it seems like there never was a fundamental difference
>about what had to be changed in the interface and its implementation.
>Please let me summarize the controversial issues:
>- Joerg wants the driver to guarantee that a command won't fail
> because of insufficient memory - definitely a must for secure
> CD writing. This is provided if the application plays by the rules and
> does not send more than one command and only with less data than
> guaranteed to be safe by SG_GET_RESERVED_SIZE.
> Please correct me if I misunderstood something here...
Right, there is a need for a guaranteed value.
The idea that an application should handle the results of a lack of
memory in such a case is really funny. Just let's assume that the filesystem
code would fire up a request to the hard disk driver and gets ENOMEM
back....
>- Raising this limit may be attempted with SG_SET_RESERVED_SIZE, but
> requires SG_GET_RESERVED_SIZE to get the result of the operation,
> which according to Joerg is not "how interfaces in a POSIX enviroment
> are implemented". I must admit that I don't understand this criticism:
> my impression was that ioctl() could be used to accomplish all kinds
> of completely different things.
>
> Even if there is some convention about how errors are reported
> (which Joerg without doubt is more familiar with than I am), then to
> me the way it is done makes sense:
>
> Assume SG_SET_RESERVED_SIZE would report an error when failing to
> allocate the requested buffer instead of using a smaller one. How
> would you find out how much smaller the buffer size must be for the
> call to succeed? The way it is handled now perfectly matches libscg's
> scsi_maxdma() - try to set a certain buffer size, then tell how much
> is actually possible.
It makes no sense to talk about this interface anymore. You cannot change it
without making sure that all old Linux kernels around have been eliminated.
This is why it is important to think about a new interface _before_
you publish it.
>>>Or does the driver deallocate a buffer although this is not mentioned
>>>in the documentation?
>>
>> I am not sure which version of the docomentation you are referring to. It
>> has been changed many times like the interface of the sg driver.
>See above for the version. Has the interface really changed that often?
>I am only aware of the "old" version, 2.x with SG_GET/SET_RESERVED_SIZE
>and now the most recent one in linux 2.4.x.
It did change at least once. That is at least once too often.
This is why it is so important to hide unstable interfaces before
you are sure that it may last for some years.
>>>> 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.
>>
>> The drive(s) that have been specified by scsi_open()
>>
>>>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.
>>
>> You may use this feature if you open a SCSI * handle for scanning.
>> This is done by using a NULL pointer for char *scsidev.
>> An empty string should work too.
>At the moment I call scsi_open() with only bus, target and lun (i.e.
>NULL scsidev) even if I only want to use one drive, because that's the
>only information I have. The Amiga scsi.device identifies drives this
>way, so I obtain a list of available drives and their bus/target/lun
>each time the emulator is started.
>Do I have to build a scsidev string that repeats the bus/target/lun
>values like in the cdrecord "dev=" argument, or wouldn't it be better
>to accept the tuple "scsidev NULL, bus/target/lun != -1" as another way
>to open a SCSI handle for just one drive?
It looks as if you are using inofficial interfaces that are not allowed
to be used by endusers. The scsi_open() interface may be changed every
day, open_scsi() is the public interface.
>> I don't understand what you mean. If you believe that I should force
>> the application to reserve space before the DMA buffer, then you are
>> on the wrong way. Why should I force my application to do silly things
>> just for the sake of one ill defined OS interface?
>No, of course not, and that wasn't what I meant. You said "the 2.4 kernels
>introduce an ioctl() implementation that does not have limitations on the
>DMA address anymore". What I wanted to know was: are you talking about
>a limitation different from the one that the data has to follow the
>header directly?
No, but this is the important limitation.
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]
