Re: What should be done with wrong warning "please use bus_type methods." on sd, sr, st and osst?

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2008-03-25 at 23:20 +0100, Éric Piel wrote:
> 24/03/08 19:16, James Bottomley wrote/a écrit:
> > On Mon, 2008-03-24 at 10:59 -0700, Greg KH wrote:
> >> On Mon, Mar 24, 2008 at 10:24:07AM -0500, James Bottomley wrote:
> >>> A solution would be to duplicate the power management methods in the
> >>> scsi_driver structure, but this is a complete waste of space since the
> >>> generic driver ones aren't going away (at least according to Kay and
> >>> Greg).  I still think the best thing to do is just to turn off this
> >>> spurious warning.
> >> Do you have a patch that can detect the usage that you currently have so
> >> that I can change the warning message to not trigger if things are set
> >> up that way instead?
> > 
> > Well, my suggested fix would be the attached one since you and Kay seem
> > to be telling me that converting to bus_type X methods still leaves us
> > free to reuse the driver X methods.  If you're planning on deprecating
> > the driver X methods, then sure, it makes sense for me to duplicate them
> > in the scsi driver.
> 
> I guess the problem with removing the warning is that in some other
> cases it could really be useful (searching on the web seems to show a
> couple of true positives).  I think Greg was more suggesting like adding
> a flag ".i_know_what_i_am_doing" somewhere and putting it to 1 to
> disable the warning.

Sure, but I just see all the fallout from the false positive on SCSI
(Like about one email a week suggesting that I fix it), so I'm
complaining about my particular piece of this.

> Anyway, if the driver X methods are meaning something else, it makes
> sense to duplicate them specifically in the scsi driver structure. We are
> basically talking about 8 bytes per scsi device, which can be considered
> a fair trade-off if it allows to detect bugs in other places of the
> kernel. Following is an example of patch.

Well, what I'd like is to establish whether this usage is correct.  I do
think that if the probe and remove methods aren't going away, then it
is,

> PS: Probably I'm an idiot, for the patch I didn't understand how to
> move ".remove" to scsi_driver, so I moved it to scsi_device... anyway it's
> just an example in order to be sure that everyone is talking about the
> same thing.

No ... it's a reasonable approach.  The struct scsi_device isn't quite
the right place to do it ... we have one struct scsi_driver for each ULD
(that's sd, sr, st etc,)  We have one struct scsi_device for every
device you have in the system (which can be thousands in an enterprise
system), so putting the method in struct scsi_device is a bit of
duplication overkill, but moving it to struct scsi_driver is very
feasible.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html