> >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!
As I haven't followed the complete history (especially including
publishing dates) I am not able to directly relate this date to
a interface definition.
> >> 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.
As far as I can tell, the new interface was well defined and ready to
be used by applications. That SG_SET_RESERVED_BUFFER was a NOOP didn't
affect binary compatibility with programs using the new interface,
because it was specified that this command might not do anything.
> >> 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.
And SG_GET_RESERVED_BUFFER provides this guarantee.
> The idea that an application should handle the results of a lack of
> memory in such a case is really funny.
But the sg driver doesn't expect an application to do this, don't you
think so? An sg application has to test the current maximum transfer
length only once with SG_GET_RESERVED_BUFFER (just like an libscg
application with scsi_maxdma()), then it can send commands without
bothering about memory constraints.
> >>>> 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.
Then it was a typo when you said "The drive(s) that have been specified
by scsi_open()" above and it should have been "open_scsi()"?
How can I distinguish inofficial and official interfaces? Both
open_scsi() and scsi_open() are defined in scsitransp.h without
comments. Again, I think this shows the need for more documentation.
I'll use open_scsi() with a NULL scsidev to do a bus scan.
How can I build a scsidev string to open another SCSI pointer to
access just one drive in a portable way?
Bye, Patrick Ohly
--
Sent through GMX FreeMail - http://www.gmx.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
