On Mon, Jul 28, 2008 at 11:05 AM, Ingo Molnar <mingo@xxxxxxx> wrote:
> * Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
>>
>> Today's linux-next merge of the kmemcheck tree got a conflict in
>> init/main.c between commits c2147a5092cfe13dbf3210e54e8a622015edeecc
>> ("Better interface for hooking early initcalls") and
>> 7babe8db99d305340cf4828ce1f5a1481d5622ef ("Full conversion to
>> early_initcall() interface, remove old interface") from Linus' tree
>> and commit 385e31b9eae0528bada07d16a189f3f40df23961 ("kmemcheck: add
>> the kmemcheck core") from the kmemcheck tree.
>>
>> I used the upstream version and turned kmemcheck_init into an
>> early_initcall().
>
> 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().
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
--
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
