Re: RFC: [2.6 patch] let BLK_DEV_UB depend on USB_STORAGE=n

[Pete Zaitcev]

On Mon, 24 Jan 2005 11:48:51 +0000, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:

> On Wed, 2005-01-19 at 14:07 -0800, Greg KH wrote:
> > I have been running with just the code portion of this patch for a while
> > now, with good results (no Kconfig changes.)
> > 
> > Pete and Matt, do you mind me applying the following portion of the
> > patch to the kernel tree?
> > 
> > > -#if !defined(CONFIG_BLK_DEV_UB) && !defined(CONFIG_BLK_DEV_UB_MODULE)
> > >  UNUSUAL_DEV(  0x0781, 0x0002, 0x0009, 0x0009, 
> > >  		"Sandisk",
> > >  		"ImageMate SDDR-31",
> > >  		US_SC_DEVICE, US_PR_DEVICE, NULL,
> > >  		US_FL_IGNORE_SER ),
> > > -#endif
> 
> Urgh. Please do. Code which may compile differently in the kernel image
> according to which _modules_ are configured at the time is horrid, and
> should be avoided.

The fallacy of this "urgh" is easy to demonstrate when you consider usb-storage
and ub the one and the same driver. Initially, ub was just a mode for
usb-storage ("threadless"). I only factored them separate for reasons
of clarity. Horrid, indeed. There's no reason to build one statically
and another as a module.

Mind, I didn't disagree with the backout patch as such, but not because
it was a good idea, but because it may help to shut up a few stupid users
(provided that our scripts preserve the link order from drivers/usb/Makefile
in modules.usbmap, or have other way to make sure that usb-storage entries
are ahead of ub entires; did anyone actually check it? if those scripts
sort by name, ub still pops ahead, and the backout is utterly ineffectual).

When we reintroduce ub in Fedora, I'll just put this patch right back,
it's not a problem. But please think about this issue a little more,
you might want to take the Urgh back.

-- Pete
-
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/