From: "Vegard Nossum" <vegard.nossum@gmail•com>
To: Ingo Molnar <mingo@elte•hu>
Cc: Stephen Rothwell <sfr@canb•auug.org.au>,
Pekka Enberg <penberg@cs•helsinki.fi>,
linux-next@vger•kernel.org,
Eduard - Gabriel Munteanu <eduard.munteanu@linux360•ro>
Subject: Re: linux-next: manual merge of the kmemcheck tree
Date: Mon, 28 Jul 2008 11:17:31 +0200 [thread overview]
Message-ID: <19f34abd0807280217n2c059cfkaeb194fed3f72ba9@mail.gmail.com> (raw)
In-Reply-To: <20080728090530.GA5732@elte.hu>
On Mon, Jul 28, 2008 at 11:05 AM, Ingo Molnar <mingo@elte•hu> wrote:
> * Stephen Rothwell <sfr@canb•auug.org.au> 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
next prev parent reply other threads:[~2008-07-28 9:17 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-28 4:01 linux-next: manual merge of the kmemcheck tree Stephen Rothwell
2008-07-28 9:05 ` Ingo Molnar
2008-07-28 9:17 ` Vegard Nossum [this message]
2008-07-28 9:29 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2008-12-30 12:18 Stephen Rothwell
2008-12-30 12:14 Stephen Rothwell
2008-10-28 5:14 Stephen Rothwell
2008-10-28 8:15 ` Ingo Molnar
2008-10-21 5:29 Stephen Rothwell
2008-10-21 7:32 ` Ingo Molnar
2008-10-21 8:07 ` Vegard Nossum
2008-10-21 8:28 ` Ingo Molnar
2008-10-21 5:15 Stephen Rothwell
2008-08-20 6:40 Stephen Rothwell
[not found] <20080815164909.3d8beb10.sfr@canb.auug.org.au>
2008-08-15 7:04 ` Vegard Nossum
2008-08-15 8:00 ` Stephen Rothwell
2008-08-15 6:45 Stephen Rothwell
2008-08-15 6:43 ` Pekka Enberg
2008-08-15 8:17 ` Ingo Molnar
2008-08-13 5:29 Stephen Rothwell
2008-08-13 7:32 ` Ingo Molnar
2008-08-13 7:31 ` Pekka Enberg
2008-08-13 7:58 ` Ingo Molnar
2008-08-13 8:14 ` Pekka Enberg
2008-08-13 8:58 ` Ingo Molnar
2008-08-13 11:37 ` Pekka Enberg
2008-08-13 11:52 ` Ingo Molnar
2008-08-13 11:57 ` Pekka Enberg
2008-08-13 12:05 ` Ingo Molnar
2008-08-13 7:41 ` Stephen Rothwell
2008-08-13 5:26 Stephen Rothwell
2008-08-13 5:22 Stephen Rothwell
2008-07-28 4:09 Stephen Rothwell
2008-07-28 9:06 ` Ingo Molnar
2008-07-28 17:19 ` Stephen Rothwell
2008-07-22 6:16 Stephen Rothwell
2008-07-22 6:52 ` Ingo Molnar
2008-07-22 8:18 ` Stephen Rothwell
2008-07-21 6:47 Stephen Rothwell
2008-07-11 6:32 Stephen Rothwell
2008-07-03 6:19 Stephen Rothwell
2008-07-03 6:12 Stephen Rothwell
2008-07-03 6:26 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19f34abd0807280217n2c059cfkaeb194fed3f72ba9@mail.gmail.com \
--to=vegard.nossum@gmail$(echo .)com \
--cc=eduard.munteanu@linux360$(echo .)ro \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=mingo@elte$(echo .)hu \
--cc=penberg@cs$(echo .)helsinki.fi \
--cc=sfr@canb$(echo .)auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox