From: "H. Peter Anvin" <hpa@kernel.org>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
torvalds@linux-foundation.org, mingo@kernel.org,
tglx@linutronix.de, Paul Mundt <lethal@linux-sh.org>
Subject: Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds
Date: Thu, 17 May 2012 20:21:52 -0700 [thread overview]
Message-ID: <4FB5C050.9070805@kernel.org> (raw)
In-Reply-To: <4FB58EFD.7010302@zytor.com>
On 05/17/2012 04:51 PM, H. Peter Anvin wrote:
>
> This patch and the one before it seems to have another problem: we
> currently define __BITS_PER_LONG as:
>
> #ifdef __x86_64__
> # define __BITS_PER_LONG 64
> #else
> # define __BITS_PER_LONG 32
> #endif
>
H.J., do you see any problem *other* than this wretched struct
msqid64_ds with changing the above from __x86_64__ to
#if defined(__x86_64__) && !defined(__ILP32__)
... in the above?
As far as struct msqid64_ds, I think we can fix it simply because x86
is the only compat-aware architecture which has to deal with it.
(Incidentally, if sh is ever expanded to 64 bits, it will have a problem
in the bigendian configuration...)
-hpa
next prev parent reply other threads:[~2012-05-18 3:22 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
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 [this message]
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=4FB5C050.9070805@kernel.org \
--to=hpa@kernel.org \
--cc=hjl.tools@gmail.com \
--cc=lethal@linux-sh.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.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.