Messages in this thread | | | Date | Sun, 07 Mar 2010 08:37:15 -0800 | From | Randy Dunlap <> | Subject | Re: modules, "modules" and CONFIG_LIST_SORT |
| |
On 03/07/10 03:23, Linus Torvalds wrote: > > > On Sun, 7 Mar 2010, Alexey Dobriyan wrote: >> >> Unpleasant side effect of the change is that some modules stop being >> true modules, i. e. admin is unable to start using them without reboot >> if kernel was compiled without that tiny amount of core kernel. >> >> Having used this feature several times, I think it'd be correct >> to preserve this behaviour, at least not regress for those modules >> which benefitted from it. For modules which were always "modules" (ipv6) >> it's fine to continue. >> >> Can we declare some policy about it? >> >> And revert LIST_SORT commit if yes. > > Yeah, I think that in cases like this, you have a very good argument: > LIST_SORT enables code that isn't that large, and is clearly very generic. > > And changing the config later and trying to compile and install a module > is rather sane. And if that new module needs LIST_SORT, you're screwed > because it didn't get compiled in originally. > > Honestly, personally I'd rather have a real library that modules can link > to _before_ even loading into kernel space, but that's not how we've > traditionally done things. So I guess we should just revert that commit.
xfs also needs "select LIST_SORT". I posted a patch for that a few days ago and now Christoph Hellwig has asked me to send the patch directly to Linus, but if Linus is going to revert the 'config LIST_SORT' patch, I'll skip it.
-- ~Randy
| |