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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
