From: "H. Peter Anvin" <hpa@zytor.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
David Daney <ddaney.cavm@gmail.com>,
Ralf Baechle <ralf@linux-mips.org>,
"H.J. Lu" <hjl.tools@gmail.com>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
mingo@kernel.org, tglx@linutronix.de
Subject: Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds
Date: Fri, 18 May 2012 15:08:34 -0700 [thread overview]
Message-ID: <4FB6C862.5060401@zytor.com> (raw)
In-Reply-To: <201205182158.59616.arnd@arndb.de>
On 05/18/2012 02:58 PM, Arnd Bergmann wrote:
>
> But why do you think it's wrong the way it is? I see the idea of putting
> padding in varying places depending on the endianess as a failed experiment
> and defining a structure that is always the same as the logical conclusion
> from that, even if it's a bit silly to have any padding in it at all.
>
The *whole point* is to make the structure the same across modes, to
make the compat layer's job easier.
> Being consistent seems more important here than following the intent
> of whoever came up with the concept of the ipc64 data structures
> and was consequently ignored by most people after him.
So you're saying because some architectures introduced a bug, we should
*CONTINUE* to introduce the same bug?? WTF??
> If we really wanted the data structures to be compatible between 32 and
> 64 bit mode, we'd have to use __u64 here but that would mean having to
> change all bits of user code that already rely on the existing x86
> compatible layout.
x86 is doing it right. Some bigendian architectures blindly copied what
x86 was doing without thinking. That's a bug on their part, period.
-hpa
next prev parent reply other threads:[~2012-05-18 22:08 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-17 22:13 [RFC PATCH 00/10] Use __kernel_[u]long_t for x32 user space compatibility H.J. Lu
2012-05-17 22:13 ` [PATCH 01/10] Use __kernel_long_t in struct timex H.J. Lu
2012-05-17 22:32 ` Linus Torvalds
2012-05-17 22:41 ` H. Peter Anvin
2012-05-17 22:50 ` H. Peter Anvin
2012-05-17 22:50 ` Linus Torvalds
2012-05-17 22:55 ` H. Peter Anvin
2012-05-17 22:58 ` Linus Torvalds
2012-05-17 22:56 ` Linus Torvalds
2012-05-17 22:57 ` H. Peter Anvin
2012-05-17 23:51 ` David Daney
2012-05-17 22:13 ` [PATCH 02/10] Use __kernel_ulong_t in struct shm_info H.J. Lu
2012-05-17 22:13 ` [PATCH 03/10] Use __kernel_[u]long_t in linux/resource.h H.J. Lu
2012-05-17 22:13 ` [PATCH 04/10] Use __kernel_long_t in struct msgbuf H.J. Lu
2012-05-17 22:13 ` [PATCH 05/10] Use __kernel_long_t in struct mq_attr H.J. Lu
2012-05-17 22:13 ` [PATCH 06/10] Use __kernel_ulong_t in x86 struct semid64_ds H.J. Lu
2012-05-17 22:13 ` [PATCH 07/10] Use __kernel_ulong_t in struct shmid64_ds/shminfo64 H.J. Lu
2012-05-17 22:13 ` [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds H.J. Lu
2012-05-17 23:51 ` H. Peter Anvin
2012-05-18 0:07 ` Linus Torvalds
2012-05-18 0:14 ` H. Peter Anvin
2012-05-18 0:22 ` Linus Torvalds
2012-05-18 0:27 ` H. Peter Anvin
2012-05-18 0:41 ` Linus Torvalds
2012-05-18 11:44 ` David Howells
2012-05-18 21:31 ` Arnd Bergmann
2012-05-18 21:41 ` H. Peter Anvin
2012-05-18 21:58 ` Arnd Bergmann
2012-05-18 22:08 ` H. Peter Anvin [this message]
2012-05-19 7:56 ` Arnd Bergmann
2012-05-19 14:35 ` Al Viro
2012-05-18 0:29 ` David Daney
2012-05-18 0:31 ` H. Peter Anvin
2012-05-18 0:45 ` David Daney
2012-05-18 0:37 ` H. Peter Anvin
2012-05-18 15:03 ` Chris Metcalf
2012-05-18 15:03 ` Chris Metcalf
2012-05-18 3:21 ` H. Peter Anvin
2012-05-18 3:39 ` H.J. Lu
2012-05-18 3:43 ` H.J. Lu
2012-05-18 3:47 ` H.J. Lu
2012-05-18 3:49 ` Linus Torvalds
2012-05-18 3:55 ` H. Peter Anvin
2012-05-18 3:59 ` H.J. Lu
2012-05-18 4:05 ` Linus Torvalds
2012-05-18 4:13 ` H.J. Lu
2012-05-18 21:21 ` Arnd Bergmann
2012-05-19 23:47 ` H. Peter Anvin
2012-05-20 1:32 ` H.J. Lu
2012-05-20 2:08 ` H. Peter Anvin
2012-05-18 11:53 ` David Howells
2012-05-18 12:06 ` H.J. Lu
2012-05-18 3:56 ` H.J. Lu
2012-05-18 21:06 ` H. Peter Anvin
2012-05-17 22:13 ` [PATCH 09/10] Use __kernel_ulong_t in struct ipc64_perm H.J. Lu
2012-05-17 22:13 ` [PATCH 10/10] Use __kernel_[u]long_t in x86-64 struct stat H.J. Lu
2012-05-17 23:07 ` [RFC PATCH 00/10] Use __kernel_[u]long_t for x32 user space compatibility David Daney
2012-05-17 23:07 ` David Daney
2012-05-17 23:07 ` David Daney
2012-05-17 23:11 ` H. Peter Anvin
2012-05-17 23:25 ` David Daney
2012-05-17 23:31 ` H. Peter Anvin
2012-05-18 0:19 ` Mike Frysinger
2012-05-18 0:21 ` H. Peter Anvin
2012-05-18 0:38 ` Mike Frysinger
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=4FB6C862.5060401@zytor.com \
--to=hpa@zytor.com \
--cc=arnd@arndb.de \
--cc=ddaney.cavm@gmail.com \
--cc=hjl.tools@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=ralf@linux-mips.org \
--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 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.