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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
