>> First I've heard of it... Is it too late for input? (I'm not on the
>No it is not.
Excellent. I was unaware of Grant's work on PG until it was too late.
>> As one of the developers pushing the Linux SG driver hardest (the
>> Paranoia project), I'm of the opinion that the driver does not need to
>> be enhanced; it needs to be replaced with something that wasn't
>> originally cobbled together for a single application. The design was
>> underpowered, the implementation badly flawed.
>Your opinion seems to be similar to Joerg Schilling (author of cdrecord)
>who also thinks it should be thrown out and replaced with something like
>the 'scg' interface that he wrote for Sun equipment (copyrighted in
>1986).
>I believe he is working on something with Heiko Eissfeldt and I would
>have expected to see some output by now. I have emailed both these
>gentleman and Eric Youngdale canvassing their opinions.
Ah! You reminded me that Heiko is involved here. He has, in fact,
produced enhanced SG patches. Heiko, I've included you in these
replies from here on in...
On the subject of SCG:
I have my own issues with CAM (and scg is CAM-ish), but I'd accept an
implementation that uses it.
I prefer the BSD (and Solaris' USCSI is very similar) generic SCSI
interface. With it, it's possible to open any specialized device and
send generic packet commands to the device. In the linux idiom, an
example would be opening /dev/sr0 or /dev/scanner and being able to
send raw packet commands (if permissions allow) using an ioctl().
I prefer this approach to CAM (in which all SG devices are equal, and
must be attached to a SCSI host/target/lun after opening) because it
matches the UNIX idiom more closely. The CDROM, for example, is not
0:2:0... it's /dev/cdrom or /dev/sr0 in the same way that under
windows, it may be 'drive E:' or 'My CDROM'. In Linux, especially,
with the advent of movable majors and making just about everything
absurdly customizable, reliable identification of particular devices
and device types is becoming more difficult. Any generic SCSI device
addressing scheme needs to take this issue into account. (Most of
the Linux-specific code in Paranoia has to do with figuring out what a
device type is in such a way that doesn't break for anyone who enjoys
customizing a little too much).
Even with the manpage, source README, Web page FAQ, Web page
'troubleshooting guide' and finally code to specifically detect
confused users that explains the generic devices, I *still* get mail
(averaging about 2 messages a day) that read 'my cdrom is /dev/cdrom
and it works fine with cdplayer and xmcd! Why is cdparanoia not
working? It says 'cannot find generic device to match /dev/cdrom'...
This device dichotomy is not unheard of in UNIX... but nor is it
necessary in this case. In addition, the process of matching
/dev/cdrom (whatever it's linked to) to the appropriate /dev/sg or
/dev/pg or /dev/hd or /dev/sr, etc, device can only be done by
exhaustive search with a large number of error conditions that was
*not even possible* until recent kernels and is horribly complicated
by modules, movable majors, device permission, kernel options, etc.
Paranoia IV (at this point before release) devotes 600-1000 lines of
code under Linux to intelligent handling of these various
cases. Putting the burden on the user to fill in the appropriate
device options everytime he runs the application is not acceptible;
remember that each application is requiring the user to know this
arcane information in a different format ("I don't care what the
target number is... I want to use my CDROM!"). A large amount of that
Paranoia code would disappear if /dev/cdrom had a generic packet
ioctl() interface ala BSD (and that interface was guaranteed to be in
the kernel). The code would not get shorter (and might get longer) if
Linux goes to CAM. The BSD interface results in simpler code that
makes applications simpler and easier to write. Users see this as
more reliable, easier to use software.
>The only advantage of using and extending the existing interface is
>backward compatibility with a lot of existing applications. I replied
>to GOTO Masanori because he described a serious flaw of the original
>implementation in which 2 sg devices are accessed and they contend for
>the SG_BIG_BUFF.
There are many more... To begin, interleaving results with the wrong
command, complete inability to detect any error condition properly
(although it does return sense so that the application can look for
some thinsg itself), constant lockup, the fact that regardless of the
outcome of the command, SG always returns the number of bytes you told
it to expect (even if those bytes are uninitialized garbage), etc...
> My implementation should cure that without
>(hopefully) any side effects. Also he is actively developing, so
>changing his interface to try out some of the extensions should not be
>too difficult.
Good. With luck, no one would complain too much about getting
something better than currently exists. :-) I hate changing
interfaces, but I'd like to see it happen in this case...
>> I've read the rest of your message below describing enhancements; it
>> appears you have a pretty good grip on what SG needs to do, what
>> needed to be corrected and how to do it, so I don't think I need to do
>> any flaming. I have a few questions, and I'd like to offer one
>> important 'demand' that I consider vital to Linux in general.
>Using the existing sg interface (plus some extensions) is the easiest
>way for alpha tester to evaluate my implementation. I am not wedded
>to that interface and if the implementation is strong enough its
>interface could be changed, or multiple interfaces could be given
>to the same implementation.
Your development route was rational; whatever happens you have tested
implementation guts.. I would comment that whatever interface we
eventually settle and agree on, we should keep it to one and kill the
preceeding ones as quickly as possible. Note that I'm adressing the
generic packet interface here and not specialized interfaces (although
some of them, especially CDROMREADAUDIO, need fixed or possibly
eliminated).
>> What needs to happen to SG, PG, ATAPI, et al is not a piecemeil
>> improvement of a single interface that further complicates
>> compatability issues for minimal gain, but a redesign and unification
>> that takes into account the practical programming experience of the
>> folks using it as well as the wisdom of preceeding systems. Above all
>> the interfaces must be *uniform*. If we're going to break with a
>> current interface, I'd like to see Linux go all out, break totally
>> with what's there and get a new interface set that's clean and above
>> all unified (right now, Paranoia has seperate Linux code at various
>> levels for ATAPI cooked ioctl() interfaces, ATAPI using SG with
>> IDE-SCSI, generic SCSI, and PG the parallel port raw ATAPI interface.
>> This is rediculous. And Joerg: No flames. Alpha 10 is based heavily
>> on your code at the transport level ;-).
>This all sounds extremely sensible.
I included this for Heiko's and Jens's benefit :-)
>> Before the high-level driver holy wars start again, I'm aware of the
>> limitations of Linux's internal VFS and device layers. There's no
>> practical way, without redesigning the kernel, or acheiving true
>> unification of the interfaces through a single kernel device. What
>> *is* possible is design of a uniform generic interface standard that
>> is enforced across the different hardware devices such that in user
>> space the divisions are seamless. All four of the above obey the same
>> commands, dammit!
>Well then you will need those 4 drivers to be actively maintained and
>the individuals concerned prepared to work with one another and once
>a unified interface is in place, collectively reject most, but not all,
>suggestions from the application writers :-)
I realize this. Under normal circumstances, it's not the engineering
route I'd choose and not the one I originally flamed people about
(Grant still probably hates me...) Given the current design of the
Linux kernel, however, I'm convinced that the chance of succeeding
with parallel, identical interfaces is much greater than trying to
unify SCSI/ATAPI/PARIDE into a truly unified device layer. Not only
would the changes required for complete unification affect way too
much of the kernel (or, if done to minimize impact, be too much of an
unmaintainable hack), the number of kernel developers who would be
dragged into those changes would cause alot of pain and resistance.
If I fail to convince you, I'm sure Grant or Gadi can do a better job;
these arguments are originally theirs :-)
>Didn't know about the kernel buffer clobber, tell me more (perchance
>I replicated that feature).
Note that I didn't mean overrun, I meant clobber. In current SG, if
you inform the driver you're expecting (eg) 4k of data to return from
the command, it will hand you back 4k of data regardless of what the
target actually sent (even if the target sent nothing or terminated
the command). If you request/expect 4k, and the target returns 3k, SG
hands you back 3k of returned data + 1k of garbage, with a read count
of '4k'.. What I do is stuff the original input packet with known
values to clobber the transfer buffer with data I'll recognize when
the result comes back (the buffer is reused for sending the command
and reading the results). The packet command is well formed with the
proper amount of data to be sent to the target, but SG still
faithfully copies every byte passed to the input buffer. So when I
read back a result with 'uninitialized' data, I can recognize the
(usually) impossible values I stuffed in.
Although I do code for possibilities that I've never seen happen, I
have watched this case happen and traced it through the kernel. My
hack works; I detect 'underruns' that, eg, cdda2wav/libscg would never
know about (I've verified they slip past that implementation).
>In my implementation's case doing a "#ifdef SG_SCATTER_SZ" or a
>"ioctl(sg_fd, SG_GET_PACK_ID ...)" will differentiate the original sg
>driver from my driver. Perhaps there should be a version number in
>there as well...
So long as differentiating with with that ioctl is documented and
supported, I see no problem with using it. Oh, the ioctl value needs
to be registered/reliable. Other enhanced SG patches out there also
add ioctl()s.... if two happen to have the same magic
number.... *boom*.
>> You obviously have a firm grip of the state of SG and how to implement
>> better. Grant Guenther (author of the PG interface) has also told me
>> that he'd like to see such a unified interface and is willing in
>> general to move PG to such an interface. We have, unfortunately, lost
>> Gadi Oxman (author of SCSI-IDE emulation) to the real world, but
>> perhaps he's still willing to offer advice.
>There should be no problem at this end co-operating with these people.
Yay!
Monty
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
