public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-scsi@vger.kernel.org, pcihpd-discuss@lists.sourceforge.net,
	schwidefsky@de.ibm.com, Greg K-H <greg@kroah.com>
Subject: Re: [CFT 1/29] Add bus_type probe, remove, shutdown methods.
Date: Fri, 6 Jan 2006 16:57:17 +0000	[thread overview]
Message-ID: <20060106165717.GB16093@flint.arm.linux.org.uk> (raw)
In-Reply-To: <1136565289.3528.26.camel@mulgrave>

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

      reply	other threads:[~2006-01-06 16:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060105142951.13.01@flint.arm.linux.org.uk>
2006-01-05 14:44 ` [CFT 29/29] Add Pseudo LLD bus_type probe and remove methods Russell King
2006-01-10  6:00   ` patch add-pseudo-lld-bus_type-probe-and-remove-methods.patch added to gregkh-2.6 tree gregkh
2006-01-06 11:48 ` [CFT 1/29] Add bus_type probe, remove, shutdown methods Russell King
2006-01-06 16:34   ` James Bottomley
2006-01-06 16:57     ` Russell King [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060106165717.GB16093@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=James.Bottomley@SteelEye.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=pcihpd-discuss@lists.sourceforge.net \
    --cc=schwidefsky@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox