Hello again,
(Sorry about the week delay. Work has had me hosed into the ground.)
>> produced enhanced SG patches. Heiko, I've included you in these
>> replies from here on in...
>
>Folks, I'd be willing to set up a linux-packet mailing list (or whatever
>we'd like to call it) for the interested parties to this discussion, although
>perhaps linux-scsi is quiet enough that we can take it over ;-)
If you want to set up the list, great. Linux-scsi is pretty quiet,
but I appreciate even a minimal reduction in email load (which
accounts for most of my day). If we do, we should probably forward
list messages to linux-scsi such that others will see the discussion.
>> 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 don't know if anybody has noticed, but this interface _does_ already
>exist in Linux. It's been there for a long time. All SCSI devices
>accept the SCSI_IOCTL_SEND_COMMAND ioctl(). The interface was officially
>deprecated (and hidden ?) when the sg driver was introduced. I used it
>in my prototype of the "ziptool" program for managing the Iomega proprietary
>functions of the ZIP drives. I believe that all the successors to my
>program still use that interface.
!!! How the heck did I miss this?
>I recall there are or were some issues with the size of the data blocks
>that could be passed to any ioctl, but perhaps that's now been addressed.
OK, worth looking into. Are you aware of any other issues relating to
why SG was developed to replace the BSD style interface? Talk about
heading backward..
(Well, I haven't looked at how good the BSD style implementation is yet)
>It's my opinion that the long-term function of the 'sg' driver should be
>as a kind of placeholder that does nothing more than produce a device name
>for SCSI devices that cannot be assigned to the 'sd', 'sr' or 'st' drivers.
>(In my own domain, I could eliminate the pg driver and implement a
>common packet command ioctl in the pf, pcd and pt drivers.)
Hmmm... I like this idea. I don't have alot to add to it in the
general sense.
>If due consideration is given to the peculiarities of the ATAPI and PARIDE
>devices during the rehabilitation of this interface, we should all be
>able to incorporate it into our drivers with predictable behaviour.
>(Similar, I suppose, to the way many drivers recognise the CD-ROM eject
>ioctl and act appropriately.)
Yes. The way I envision the interfaces to work is two-level (and I
imagine this is also what you see Grant); the raw packet command
interface is meant to be a way to get at devices for which there is no
available specialized interface, or to address features of an
otherwise standard device that rely on nonstandard commands.
Specialized interfaces are for accessing uniform or mostly uniform
features of a class of devices.
CDDA is, of course, a great example of this; implementing a good CDDA
interface in the kernel is a bad idea due to the extreme difficulty of
implementing it universallay and at all reliably. OTOH, other
features of a typical CDROM drive are uniform across the class, and
for these features it makes good sense to have a specialized
interface.
New hardware features generally begin in highly vendor-specific
fashion, then proceed to a uniform interface (or an interface that can
be made uniform). CDDA is moving that direction, but it won't be
there for many years to come. At the time of uniformity, a
specialized interface can be constructed.
>> (Grant still probably hates me...)
>
>Actually, I'm very happy to see this discussion starting. If I helped to
>get things moving by making a bad situation worse when I designed the pg
>interface, I think that was probably a good strategy !
Glad to hear that :-)
Monty
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
