* Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote: > > thanks Stephen. > > > > I made this fixup too, yesterday, but solved it differently: i added > > kmemcheck_init() to before all early initcalls. I think that's the > > best solution for a fundamental debug feature like kmemcheck. (which > > could catch bugs in early initcalls as well) What do you think? > > > > i've pushed out a new auto-kmemcheck-next branch, so the conflicts > > should go away on your next iteration. > > I'm sorry, I didn't have the chance to review your conflict > resolutions yet. > > But I think it's correct to use an early_initcall() -- we do catch > errors even before kmemcheck_init(); the only purpose of > kmemcheck_init is to prevent additional CPUs from going up. And that's > exactly the purpose of "early initcalls", to run just before > additional CPUs are upped. (Yeah, I did point out in review that > "presmp_initcall" would have been a better name than "early", at least > for our purposes, however, it seems that the idea was rejected.) > > Perhaps kmemcheck_init() is a misnomer as well. We are functional > before that, too. If you are looking for a different init() function, > there isn't one :-) Just an option parser, param_kmemcheck(). ok - could you please dig out Stephen's conflict resolution and send a patch against tip/kmemcheck? (or better yet, a pull request ;-) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
