[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1807101356290.4356@nanos.tec.linutronix.de>
Date: Tue, 10 Jul 2018 13:57:27 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Andy Shevchenko <andy.shevchenko@...il.com>
cc: "H. Peter Anvin" <hpa@...or.com>,
Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
Dave Hansen <dave.hansen@...el.com>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
Platform Driver <platform-driver-x86@...r.kernel.org>,
sean.j.christopherson@...el.com, nhorman@...hat.com,
npmccallum@...hat.com, linux-sgx@...r.kernel.org,
Ingo Molnar <mingo@...hat.com>,
"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v12 05/13] x86/sgx: architectural structures
On Tue, 10 Jul 2018, Andy Shevchenko wrote:
> On Fri, Jul 6, 2018 at 12:50 AM, <hpa@...or.com> wrote:
>
> > For things exported to user space use __u* and __s* types... the _t types would actually violate the C standard with respect to namespace pollution.
>
> Hmm... Coding style 5(d) allows to use uintNN_t in new code (as a
> variation of uNN choice).
But not for user space exposed headers. See 5(e) for that matter.
Thanks,
tglx
Powered by blists - more mailing lists