On Mon, Dec 13, 2010 at 03:36:02PM +0200, Felipe Balbi wrote: > On Mon, Dec 13, 2010 at 09:26:17PM +0800, Ming Lei wrote: > >2010/12/13 Felipe Balbi <balbi@xxxxxx>: > >>Hi, > >> > >>On Mon, Dec 13, 2010 at 09:15:22PM +0800, Ming Lei wrote: > >>>>> > >>>>>see size of glue modules built with this patch set in my beagle-xm: > >>>>> > >>>>>-rw-rw-r-- 1 500 500 132068 Dec 13 2010 am35x.ko > >>>>>-rw-rw-r-- 1 500 500 135279 Dec 13 2010 omap2430.ko > >>>>>-rw-rw-r-- 1 500 500 152696 Dec 13 2010 tusb6010.ko > >>>> > >>>>that's all on .init.text section, no ?!? then it'll be freed after we're > >>>>out of initcalls. > >>> > >>>No, only very few function/variables of glue driver is declared > >>>as __init, and is in .init section. Others will still stay in ram for > >>>ever. > >> > >>But what's the problem ? We want a single binary for several glue layers > >>of same ARCH anyway. When building products, device makers will > >>optimize what they think needs to be optimized, counting removing unused > >>drivers from kernel configuration. > >> > >>On a distro-like kernel we will have all of that configured to work. > >>Which is the same in both approaches (glue built-in or as module), the > >>difference is that there's not behavior change for users which have been > >>issuing 'modprobe musb_hdrc' since it has been added to mainline. OTOH, > >>if we change glue layers to modules, users will have to remember that > >>now they're running omap2plus boards and they have to type modprobe > >>musb-omap2430, instead of modprobe musb_hdrc. > > > >No, udev can do it automatically, and the default rule is enough intelligent. > > there are systems which don't use udev :-) And do they also expect to automatically load the proper drivers for any device that is randomly plugged in? No, they don't, so relying on udev to handle module loading is fine, that's what the rest of the kernel does today. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
