Re: [-mm patch] USB_LIBUSUAL shouldn't be user-visible

[Adrian Bunk <bunk@stusta.de>]

On Wed, Nov 09, 2005 at 10:41:17PM -0800, Pete Zaitcev wrote:
> On Wed, 9 Nov 2005 14:28:08 -0800, Greg KH <greg@kroah.com> wrote:
> 
> > > What about letting the two drivers always use libusual?
> > 
> > Pete?  What do you think about this patch?
> 
> It does nothing to explain how exactly the current configuration managed
> not to work, which leaves me unsatisfied. I did test the kernel to build
> correctly with libusub on and off. All we have is this:

The problem is not that it wouldn't work.
The question is whether users compiling their kernel should know 
anything about USB_LIBUSUAL.
IMHO, USB_LIBUSUAL is an internal implementation detail and there's no 
reason why a user should ever see this option.
This is what my patch does.

The next question (not attacked by my patch) is whether we really want 
two code paths in the two USB storage drivers, or whether they should 
simply always use libusual.

> > It seems that libusual.ko is not being actually built as a module, despite being 
> > set to 'm' in .config.
> 
> Which is nonsensual, because CONFIG_USB_LIBUSUAL is a boolean.
> And reub.net is down, so I cannot fetch the erroneous .config.
> 
> I suspect that Reuben did not rerun "make oldconfig" after editing
> .config or something of that nature.

The only compile errors I know about are
  USB=y, USB_STORAGE=m, USB_LIBUSUAL=y
  BLK_DEV_UB=y/m, USB=y/m, USB_STORAGE=n, USB_LIBUSUAL=y
but this issue is easily solvable (it's the drivers/usb/Makefile part 
of my patch).

> What Adrian is proposing may be a good idea or may be not, but it has
> nothing to do with the problem.

Agreed.

> -- Pete

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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