On Fri, Jan 06, 2006 at 10:34:49AM -0600, James Bottomley wrote: > On Fri, 2006-01-06 at 11:48 +0000, Russell King wrote: > > The scsi_driver business looks like being a pig to solve - so can > > SCSI folk please look at what's required to unuse these fields. > > Well, not necessarily pig. Perhaps piglet. We definitely need the > separate probe, shutdown and remove methods for each of our ULDs. > However, if they moved into the bus, since scsi_driver is always of type > scsi_bus, we could add separate probe, shutdown and remove fields to > struct scsi_driver and have the new fields in scsi_bus call those. I > have to ask, though; isn't that primarily what most other bus types are > going to be doing anyway? So doesn't it make sense to leave the fields > in the generic driver? Then the rule becomes that if the bus has the > field, we call it, and the bus routine *may* call the corresponding > generic driver field if it feels like it. Otherwise if the bus has no > callbacks, just use the generic driver ones? Firstly, having both causes confusion. As a prime example of this, see the PCIE crap - they implement both the bus_type suspend/resume methods _and_ the device_driver suspend/resume methods, despite these device_driver suspend/resume methods never ever being called. Secondly, keeping both negates the _whole_ point of this series and the previous platform device driver series - needless bloat: - the extra bloat in struct device_driver for all bus types, many of which do not have things like shutdown or suspend/resume callbacks. - the extra code bloat in many drivers to convert the struct device to something more bus specific. Also, don't you think it's wrong to keep these fields _just_ to support single case that SCSI wants to remain using the Old Way, when everything else can be (and almost has been) converted to the New Way? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
