From: "H. Peter Anvin" <hpa@zytor.com>
To: Valdis.Kletnieks@vt.edu
Cc: Arnd Bergmann <arnd@arndb.de>, "H.J. Lu" <hjl.tools@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
Richard Kuo <rkuo@codeaurora.org>,
Mark Salter <msalter@redhat.com>, Jonas Bonn <jonas@southpole.se>,
Tobias Klauser <tklauser@distanz.ch>
Subject: Re: RFD: x32 ABI system call numbers
Date: Sat, 03 Sep 2011 10:27:42 -0700 [thread overview]
Message-ID: <4E62638E.40308@zytor.com> (raw)
In-Reply-To: <19229.1315070217@turing-police.cc.vt.edu>
On 09/03/2011 10:16 AM, Valdis.Kletnieks@vt.edu wrote:
>>
>> 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?
>
About ioctl in particular, the ABI has dependencies into almost every
single driver in the Linux kernel. It is hard-coded in the kernel that
there are two paths -- native and compat. Since pointers are going to
be 4 bytes, it means we have to use the compat path.
We may be able to cheat a little bit since we encode the argument sizes
in the ioctl numbers; this solves the case of PPGETTIME/PPSETTIME for
example (in fact, this ioctl looks currently broken in compat mode!)
However, at some point the sheer number of data types that can be
consumed by ioctl is a real concern, so changing the ones we really care
about -- like timespec/timeval -- while leaving the rest intact so we
can use the compat path as a general rule would be highly useful.
-hpa
next prev parent reply other threads:[~2011-09-03 17:28 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-26 23:00 RFD: x32 ABI system call numbers H. Peter Anvin
2011-08-26 23:13 ` Linus Torvalds
2011-08-26 23:39 ` H. Peter Anvin
2011-08-27 0:36 ` Linus Torvalds
2011-08-27 0:43 ` Linus Torvalds
2011-08-27 0:53 ` H. Peter Anvin
2011-08-27 1:18 ` Linus Torvalds
2011-08-27 1:35 ` H. Peter Anvin
2011-08-27 1:45 ` Linus Torvalds
2011-08-27 1:12 ` H. Peter Anvin
2011-08-27 1:42 ` Linus Torvalds
2011-08-29 19:01 ` Geert Uytterhoeven
2011-08-29 19:03 ` H. Peter Anvin
2011-08-30 1:17 ` Ted Ts'o
2011-08-30 1:48 ` Linus Torvalds
2011-08-30 2:16 ` Kyle Moffett
2011-08-30 4:45 ` H. Peter Anvin
2011-08-30 7:06 ` Geert Uytterhoeven
2011-08-30 12:18 ` Arnd Bergmann
2011-08-30 7:09 ` Andi Kleen
2011-08-30 9:56 ` Alan Cox
2011-08-30 7:00 ` Geert Uytterhoeven
2011-09-20 18:37 ` Jan Engelhardt
2011-09-06 20:40 ` Florian Weimer
2011-08-27 0:57 ` H. Peter Anvin
2011-08-27 4:40 ` Christoph Hellwig
2011-08-29 15:04 ` Arnd Bergmann
2011-08-29 18:31 ` H. Peter Anvin
2011-08-30 12:09 ` Arnd Bergmann
2011-08-30 16:35 ` H. Peter Anvin
2011-08-31 16:14 ` Arnd Bergmann
2011-08-31 16:25 ` H. Peter Anvin
2011-08-31 16:39 ` Arnd Bergmann
2011-08-31 16:48 ` Linus Torvalds
2011-08-31 19:18 ` Arnd Bergmann
2011-08-31 19:44 ` H. Peter Anvin
2011-08-31 19:54 ` Alan Cox
2011-08-31 20:02 ` H. Peter Anvin
2011-08-31 20:55 ` Arnd Bergmann
2011-08-31 20:58 ` H. Peter Anvin
2011-08-31 19:49 ` Geert Uytterhoeven
2011-08-31 16:46 ` Linus Torvalds
2011-08-31 17:05 ` H.J. Lu
2011-09-03 2:56 ` H.J. Lu
2011-09-03 3:04 ` Linus Torvalds
2011-09-03 4:02 ` H.J. Lu
2011-09-03 4:29 ` H. Peter Anvin
2011-09-03 4:44 ` H.J. Lu
2011-09-03 5:16 ` H. Peter Anvin
2011-09-03 14:11 ` H.J. Lu
2011-09-03 5:29 ` H. Peter Anvin
2011-09-03 8:41 ` Arnd Bergmann
2011-09-03 14:04 ` Valdis.Kletnieks
2011-09-03 16:40 ` H. Peter Anvin
2011-09-03 17:16 ` Valdis.Kletnieks
2011-09-03 17:22 ` H.J. Lu
2011-09-03 17:28 ` H. Peter Anvin
2011-09-03 17:27 ` H. Peter Anvin [this message]
2011-09-04 13:51 ` Valdis.Kletnieks
2011-09-04 15:17 ` Arnd Bergmann
2011-09-04 17:08 ` Linus Torvalds
2011-09-04 18:40 ` H.J. Lu
2011-09-04 19:06 ` Arnd Bergmann
2011-09-04 19:31 ` H.J. Lu
2011-09-04 21:13 ` Arnd Bergmann
2011-09-04 21:25 ` H.J. Lu
2011-09-04 21:41 ` Arnd Bergmann
2011-09-04 22:13 ` H.J. Lu
2011-09-05 7:48 ` Arnd Bergmann
2011-09-05 15:11 ` H.J. Lu
2011-09-05 17:21 ` Arnd Bergmann
2011-09-05 19:34 ` H.J. Lu
2011-09-05 19:54 ` H.J. Lu
2011-09-05 19:59 ` H. Peter Anvin
2011-09-05 20:27 ` Arnd Bergmann
2011-09-09 21:02 ` H.J. Lu
2011-09-04 20:11 ` H. Peter Anvin
2011-09-04 19:31 ` richard -rw- weinberger
2011-09-04 19:32 ` H.J. Lu
2011-09-03 14:15 ` H.J. Lu
2011-08-31 17:09 ` H. Peter Anvin
2011-08-31 17:19 ` Linus Torvalds
2011-08-31 17:38 ` H. Peter Anvin
2011-09-01 11:35 ` Arnd Bergmann
2011-10-01 19:38 ` Jonas Bonn
2012-02-08 21:36 ` 64-bit time on 32-bit systems H. Peter Anvin
2011-09-01 13:30 ` RFD: x32 ABI system call numbers Avi Kivity
2011-09-01 14:13 ` H. Peter Anvin
2011-09-02 0:49 ` Pedro Alves
2011-09-02 1:51 ` H. Peter Anvin
2011-09-02 8:02 ` Arnd Bergmann
2011-09-02 8:42 ` Pedro Alves
2011-09-01 6:08 ` Jonas Bonn
2011-09-02 6:17 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E62638E.40308@zytor.com \
--to=hpa@zytor.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=arnd@arndb.de \
--cc=hch@infradead.org \
--cc=hjl.tools@gmail.com \
--cc=jonas@southpole.se \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=msalter@redhat.com \
--cc=rkuo@codeaurora.org \
--cc=tglx@linutronix.de \
--cc=tklauser@distanz.ch \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.