[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0910141423070.9708@gentwo.org>
Date: Wed, 14 Oct 2009 14:26:37 -0400 (EDT)
From: Christoph Lameter <cl@...ux-foundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
cc: "Luck, Tony" <tony.luck@...el.com>, Tejun Heo <tj@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"rusty@...tcorp.com.au" <rusty@...tcorp.com.au>,
"mingo@...hat.com" <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"cebbert@...hat.com" <cebbert@...hat.com>
Subject: Re: [PATCH 13/16] percpu: remove per_cpu__ prefix.
On Wed, 14 Oct 2009, H. Peter Anvin wrote:
> Okay... I also don't seem to understand the more fundamental issue here,
> which is:
>
> Why are we dropping the prefix?
That has been answered by Tejun elsewhere. It simplifies macros in many
places. Makes treatment of dynamic and static per cpu variables uniform,
solves an issue on S/390 etc.
> It may be "insufficient", but at least it stands out like a sore thumb
> and makes mistakes harder. It would be a different thing if we could
> actually use the TLS ABI, but we really can't.
Sparse annotations will be used to detect these issues. Also generally per
cpu variables are used as parameters to per cpu functions. They only work
in the context of specifically designed macros.
--
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