public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Russell King <rmk+lkml@arm.linux.org.uk>
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, 06 Jan 2006 10:34:49 -0600	[thread overview]
Message-ID: <1136565289.3528.26.camel@mulgrave> (raw)
In-Reply-To: <20060106114822.GA11071@flint.arm.linux.org.uk>

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?

James

  reply	other threads:[~2006-01-06 16:34 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 [this message]
2006-01-06 16:57     ` Russell King

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=1136565289.3528.26.camel@mulgrave \
    --to=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=rmk+lkml@arm.linux.org.uk \
    --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