Re: BUG(?): class_device_driver_link()

[Alan Stern]

On 18 Jun 2004, James Bottomley wrote:

> Well, the SCSI model for using these things isn't exactly the same as a
> more standard entity like a PCI device.
> 
> For every SCSI device the mid-layer scans, we allocate a generic device.
> 
> We have various drivers in the driver model corresponding to our Upper
> Layer Drivers (disc[sd] tape[st] etc), although there are SCSI devices
> (like processors) that will get no driver at all bound.
> 
> We then use classes to export *device* interfaces, like one class of all
> devices, another for Parallel interface devices, another for Fibre
> Channel devices and so on.
> 
> We expect the class interface to work whether or not a driver is
> present, because the class as we've implemented it is an interface to a
> device property, not a driver property (and we also expect the class
> interface to span multiple drivers...tapes and discs may all be attached
> to a parallel bus, etc).
> 
> It sounds like the mismatch is interface on device rather than interface
> on driver, but I don't see a way we could make the interface on driver
> work for us because we need the interface even if a driver isn't bound.

You could change things so that the "driver" exported to the driver-model
core really lives in the SCSI mid-layer and simply contains stubs that
reflect things like remove(), shutdown(), and so on to the actual
upper-layer driver.  Or am I missing some fundmental reason why this 
wouldn't be a good idea?

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/