[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19229.1315070217@turing-police.cc.vt.edu>
Date: Sat, 03 Sep 2011 13:16:57 -0400
From: Valdis.Kletnieks@...edu
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Arnd Bergmann <arnd@...db.de>, "H.J. Lu" <hjl.tools@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Christoph Hellwig <hch@...radead.org>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Richard Kuo <rkuo@...eaurora.org>,
Mark Salter <msalter@...hat.com>,
Jonas Bonn <jonas@...thpole.se>,
Tobias Klauser <tklauser@...tanz.ch>
Subject: Re: RFD: x32 ABI system call numbers
On Sat, 03 Sep 2011 09:40:55 PDT, "H. Peter Anvin" said:
> Valdis.Kletnieks@...edu wrote:
>
> >On Sat, 03 Sep 2011 10:41:16 +0200, Arnd Bergmann said:
> >
> >(Admittedly, I'm tuning in late on this discussion, but...)
> >
> >> For the ioctl interface however, the __u64/__s64 type in the x32 ABI
> >> must be defined with __attribute__((packed,aligned(4))) to match what
> >> the kernel implements because it emulates the x86-32 ABI.
> >
> >Is this a cast-in-stone issue, or is it still not too late to change that?
> >And if we change that, can we simplify anything?
>
> The complexity of changing that would be enormous.
Oh, I know changing the x86-32 ABI is impossible - I meant changing the
decision to emulate that ABI (as opposed to emulating the x86-64 ABI, or a
variant thereof, or something else). Or are we already commited to that
route, even if we're still trying to figure out what syscalls to include?
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists