Re: Driver 'sd' needs updating

[Nick Warne]

On Thu, 10 Jan 2008 12:27:22 -0600
James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:


> > > OK, updated to git rc7 yesterday - I now see this in syslog:
>
>    "Driver 'sd' needs updating - please use bus_type methods"
>
> > > Do I need to fix up something here?
> > 
> > No, you don't. It's harmless, a side effect of:
> > 
> > commit 751bf4d7865e4ced406be93b04c7436d866d3684
> > Author: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
> > Date:   Wed Jan 2 11:14:30 2008 -0600
> > 
> >     [SCSI] scsi_sysfs: restore prep_fn when ULD is removed
> > 
> > 
> > It would be better to silence this warning.
> > 
> > James, we need to reset prep_fn in each ULD? though it's not nice...
> 
> Really not nice ... to the extent that we shouldn't do it.  The reset
> is in exactly the correct place currently.  If we make it a
> requirement of the ULDs its duplication and someone is bound to
> forget.
> 
> It looks like the problem is the warning in
> base/driver.c:driver_register() apparently it wants an either/or for
> ->remove methods (either bus type or driver).  We're actually using
> the bus_type methods, but we also have a driver component, sigh.  I
> suppose what it's wanting is for me to add a scsi_driver type with
> remove methods ... which looks a bit silly since all of the SCSI
> drivers want different remove methods.

OK, actually, this is wierd for me now.  Is this warning ONLY generated
on modules?

I build with no modules, but do have modules enabled due to nVidia.  I
did post about a module called 'scsi_wait' being built, even though I
didn't want it/need it but can't stop it - please refer:

http://marc.info/?t=119705493500007&r=1&w=2

If this is true, what I have now is a module being built I don't
want/need and can't stop it being built, and a warning about it not
using bus_type methods anyway.

Nick
-- 
Free Software Foundation Associate Member 5508
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/