> 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 ;-)
> 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.
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.
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.)
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.)
> (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 !
> 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 :-)
What he said ;-)
--------------------------------------------------------------------------
Grant R. Guenther [EMAIL PROTECTED]
--------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
