Re: [PATCH] switch scsi upper driver probing to the driver model

[Douglas Gilbert <dougg@torque.net>]

Christoph Hellwig wrote:
> Upper drivers now use the LDM ->probe/->remove callbacks and the
> core list code.  Note that this means there is only one driver per
> scsi device and not multiple, e.g. you can't have sd _and_ sg for
> the same device.

Is that "_and_" symmetric? That is, can one have the sg
device in preference to the sd device? If so, how is
that selected?

>  Personally I think that's not a problem anymore
> with the generic SG_IO in place, but if you scream loud enough I
> could come up with a hack that makes the sg nodes a property of the
> scsi midlayer instead of a LDM-style driver and we could get the
> old behaviour back.

Christoph,
This patch would have some interesting side effects:
   - no generic interface (apart from SCSI_IOCTL_SEND_COMMAND)
     for tape devices (st and osst). While the maintainers of
     st and osst might like this, not all the user apps would :-)
   - the SG_IO ioctl in the block level
      - limits maximum transfer size to 65536 bytes
      - does not support mmap-ed IO [and would need
        something like a reserved buffer concept to do it]
      - does not support direct IO
      - needs work (debuggings)
      - does not support async IO (either does SG_IO
        in sg but it can be done other ways in sg)
   - the extra ioctls that sg defines are either fudged
     or missing. This might upset programs other than
     cdrecord; cdparanoia comes to mind

It was my understanding that the device model has been
recently modified by Greg KH to cope with the dual nature
of the interface that sg causes. Evidently similar situations
occur elsewhere in the kernel.

Whether the sg driver is an upper level SCSI driver or
part of the mid level actually makes little difference.
The sgbind patch that I canvassed the other day
actually fits well into sg's functionality being subsumed
into the mid level with a single virtual device node
(e.g. /dev/scsi or /dev/scsibind ?) for access with each
open file descriptor getting its own state.

But then there is the problem of backward compatibility...

Doug Gilbert