linux-kernel - Re: [PATCH -tip] x86: trampoline.c cleanup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <49BD2DAE.50204@goop.org>
Date:	Sun, 15 Mar 2009 09:32:46 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Jaswinder Singh Rajput <jaswinder@...nel.org>,
	Ingo Molnar <mingo@...e.hu>, x86 maintainers <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -tip] x86: trampoline.c cleanup

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@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/