Hi Ingo,
On Mon, 29 Feb 2016 09:01:43 +0100 Ingo Molnar wrote:
>
> * Stephen Rothwell wrote:
>
> > > u32?
> >
> > It would have to be __u32, but we already use int and unsigned int
> > extensively in the siginfo structure (which are both always assumed to
> > be 32 bits). So "unsigned int"
* Stephen Rothwell wrote:
> > u32?
>
> It would have to be __u32, but we already use int and unsigned int
> extensively in the siginfo structure (which are both always assumed to
> be 32 bits). So "unsigned int" probably makes most sense.
No. This whole mishap is an object lesson in why it's
Hi H.,
On Sat, 27 Feb 2016 11:35:08 -0800 "H. Peter Anvin" wrote:
>
> On February 27, 2016 11:16:44 AM PST, Dave Hansen wrote:
> >On 02/27/2016 03:41 AM, Ingo Molnar wrote:
> >> * Stephen Rothwell wrote:
> >>> > On Fri, 26 Feb 2016 09:44:00 -0800 "H. Peter Anvin"
> > wrote:
> > > _
On February 27, 2016 11:16:44 AM PST, Dave Hansen wrote:
>On 02/27/2016 03:41 AM, Ingo Molnar wrote:
>> * Stephen Rothwell wrote:
>>> > On Fri, 26 Feb 2016 09:44:00 -0800 "H. Peter Anvin"
> wrote:
> > __u64 is okay, "unsigned long" is really messy in the presence
>of 32-on-64 bit ABIs...
>>>
On 02/27/2016 03:41 AM, Ingo Molnar wrote:
> * Stephen Rothwell wrote:
>> > On Fri, 26 Feb 2016 09:44:00 -0800 "H. Peter Anvin" wrote:
>>> > > __u64 is okay, "unsigned long" is really messy in the presence of
>>> > > 32-on-64 bit ABIs...
>> >
>> > Yeah, but unfortunately, any 64 bit scalar type
* Stephen Rothwell wrote:
> Hi,
>
> On Fri, 26 Feb 2016 09:44:00 -0800 "H. Peter Anvin" wrote:
> >
> >
> > __u64 is okay, "unsigned long" is really messy in the presence of 32-on-64
> > bit ABIs...
>
> Yeah, but unfortunately, any 64 bit scalar type here will change the
> alignment of the e
Hi,
On Fri, 26 Feb 2016 09:44:00 -0800 "H. Peter Anvin" wrote:
>
>
> __u64 is okay, "unsigned long" is really messy in the presence of 32-on-64
> bit ABIs...
Yeah, but unfortunately, any 64 bit scalar type here will change the
alignment of the enclosing unions on (some) 32 bit platforms and th
On February 26, 2016 9:34:27 AM PST, Dave Hansen wrote:
>
>From: Dave Hansen
>
>Stephen Rothwell reported:
>
> http://lkml.kernel.org/r/20160226164406.065a1...@canb.auug.org.au
>
>that the Memory Protection Keys patches from the tip tree broke
>a build-time check on an ARM build because the
From: Dave Hansen
Stephen Rothwell reported:
http://lkml.kernel.org/r/20160226164406.065a1...@canb.auug.org.au
that the Memory Protection Keys patches from the tip tree broke
a build-time check on an ARM build because they changed the ABI
of siginfo.
A u64 was used for the protection
9 matches
Mail list logo