From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>,
Ingo Molnar <mingo@elte.hu>, x86 maintainers <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -tip] x86: trampoline.c cleanup
Date: Sun, 15 Mar 2009 09:32:46 -0700 [thread overview]
Message-ID: <49BD2DAE.50204@goop.org> (raw)
In-Reply-To: <alpine.LFD.2.00.0903141718120.29264@localhost.localdomain>
Thomas Gleixner wrote:
> On Sat, 14 Mar 2009, Jaswinder Singh Rajput wrote:
>
>
>> Subject: [PATCH] x86: trampoline.c cleanup
>>
>> Impact: cleanup
>>
>> - fix style problems
>>
>
> Err. This patch is a style problem itself.
>
>
>> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
>> ---
>> arch/x86/kernel/trampoline.c | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/x86/kernel/trampoline.c b/arch/x86/kernel/trampoline.c
>> index 808031a..e3b1f2e 100644
>> --- a/arch/x86/kernel/trampoline.c
>> +++ b/arch/x86/kernel/trampoline.c
>> @@ -15,7 +15,7 @@ void __init reserve_trampoline_memory(void)
>> * trampoline before removing it. (see the GDT stuff)
>> */
>> reserve_early(PAGE_SIZE, PAGE_SIZE + PAGE_SIZE, "EX TRAMPOLINE");
>> -#endif
>> +#endif /* CONFIG_X86_32 */
>>
>
> There is no need for this useless comment. The #ifdef is 5 lines
> above. Such comments are only helpful in large nested sections.
>
Not wanting to prolong this sort of boring thread, but I think there's
definitely wiggle room here. I tend to put closing comments on #endifs
even if they're quite close to their #if(def) because the syntax is so
awful, with no inherent indication of nesting. And once you have to
deal with a merge collision, or even just gradual drifting apart of the
#if/endif, the closing comment becomes very helpful.
Sure, the closing comment adds some noise too, but the fix is to reduce
the number of #ifdefs.
But in this case, I agree with tglx - the closing comment is pointless,
because its unlikely that we're going to get #ifdef nesting or any more
code between the #ifdef/endif pair.
J
prev parent reply other threads:[~2009-03-15 16:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-14 15:44 [PATCH -tip] x86: trampoline.c cleanup Jaswinder Singh Rajput
2009-03-14 16:20 ` Thomas Gleixner
2009-03-14 16:35 ` Jaswinder Singh Rajput
2009-03-14 16:58 ` Thomas Gleixner
2009-03-14 18:11 ` Jaswinder Singh Rajput
2009-03-15 4:35 ` Ingo Molnar
2009-03-15 16:32 ` Jeremy Fitzhardinge [this message]
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=49BD2DAE.50204@goop.org \
--to=jeremy@goop.org \
--cc=jaswinder@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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