From: Florian Weimer <fw@deneb.enyo.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
LKML <linux-kernel@vger.kernel.org>,
"H.J. Lu" <hjl.tools@gmail.com>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: RFD: x32 ABI system call numbers
Date: Tue, 06 Sep 2011 22:40:21 +0200 [thread overview]
Message-ID: <877h5lh0ay.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <CA+55aFyVmA_26LYaJH8dnFhwo7LWM6Ck7qFxCQvnROEHSuV_aA@mail.gmail.com> (Linus Torvalds's message of "Fri, 26 Aug 2011 17:43:40 -0700")
* Linus Torvalds:
> On Fri, Aug 26, 2011 at 5:36 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> There is *ZERO* reason to not use it. Use the standard 64-bit
>> structure layout. Why the hell would it be a new system call?
>
> Oh, I see why you do that. It's because our 64-bit 'struct stat' uses
> "unsigned long" etc.
>
> Just fix that. Make it use __u64 instead of "unsigned long", and
> everything should "just work". The 64-bit kernel will not change any
> ABI, and when you compile your new ia32 model, it will do the right
> thing too.
And even if you don't want to do that (probably somebody wants to
recompile broken applications, same rationale as for n32, see
<http://gcc.gnu.org/ml/gcc/2011-02/msg00243.html>), you can still do
the translation in user space. Then tools like strace and valgrind
just work, and you don't risk introducing kernel vulnerabilities
through broken translation code.
next prev parent reply other threads:[~2011-09-06 21:36 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 [this message]
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
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=877h5lh0ay.fsf@mid.deneb.enyo.de \
--to=fw@deneb.enyo.de \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).