[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BBA46DB.9060106@oracle.com>
Date: Mon, 05 Apr 2010 13:23:55 -0700
From: Randy Dunlap <randy.dunlap@...cle.com>
To: paulmck@...ux.vnet.ibm.com
CC: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, mingo@...e.hu,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Steven Rostedt <rostedt@...dmis.org>,
Nicholas Miell <nmiell@...cast.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
laijs@...fujitsu.com, dipankar@...ibm.com,
akpm@...ux-foundation.org, josh@...htriplett.org,
dvhltc@...ibm.com, niv@...ibm.com, tglx@...utronix.de,
peterz@...radead.org, Valdis.Kletnieks@...edu, dhowells@...hat.com,
Nick Piggin <npiggin@...e.de>,
Chris Friesen <cfriesen@...tel.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] introduce sys_membarrier(): process-wide memory barrier
(v10)
Paul E. McKenney wrote:
> On Mon, Apr 05, 2010 at 03:10:57PM -0400, Mathieu Desnoyers wrote:
>> * Randy Dunlap (randy.dunlap@...cle.com) wrote:
>>> On Mon, 5 Apr 2010 13:57:37 -0400 Mathieu Desnoyers wrote:
>
> [ . . . ]
>
>>>> +#else /* #ifdef CONFIG_SMP */
>>> I don't know that we have a known convention for that, but I would use:
>>>
>>> #else /* not CONFIG_SMP */
>>>
>>> or
>>>
>>> #else /* !CONFIG_SMP */
>>>
>>>> +
>>>> +SYSCALL_DEFINE1(membarrier, unsigned int, flags)
>>>> +{
>>>> + return 0;
>>>> +}
>>>> +
>>>> +#endif /* #else #ifdef CONFIG_SMP */
or just:
#endif /* #else #ifdef CONFIG_SMP : tell the reader that the #else part of the #ifdef CONFIG_SMP just ended */
ad nauseum.
>>> and:
>>>
>>> #endif /* CONFIG_SMP */
>>>
>>> The "#else #ifdef" is both ugly and too wordy IMO.
>
> The extra words make it very clear that we are in at the end of the #else
> clause of a #ifdef with the given condition. With "#endif /* CONFIG_SMP
> */", is the immediately preceding code compiled under CONFIG_SMP or
> !CONFIG_SMP? You have to dig back and see whether or not there is a
> #else clause.
>
> But there is no accounting for taste. ;-)
IYHO.
regards.
--
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/
Powered by blists - more mailing lists