From: "H. Peter Anvin" <hpa@zytor.com>
To: Christoph Hellwig <hch@infradead.org>,
"H.J. Lu" <hjl.tools@gmail.com>,
linux-arch <linux-arch@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ralf Baechle <ralf@linux-mips.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH 0/8] Update kernel uabi header files for x32
Date: Mon, 20 Jan 2014 09:46:41 -0800 [thread overview]
Message-ID: <52DD6101.4010708@zytor.com> (raw)
In-Reply-To: <20131228163308.GA1638@infradead.org>
On 12/28/2013 08:33 AM, Christoph Hellwig wrote:
> On Fri, Dec 27, 2013 at 02:14:16PM -0800, H.J. Lu wrote:
>> X32 uses the same kernel system call interface as x86-64 for many
>> system calls. However, "long" is 64-bit for x86-64 and is 32-bit for
>> x32. Where long or unsigned long are used in struct types for such
>> system calls, they are wrong for x32. __kernel_[u]long_t is [unsigned]
>> long for all ABIs other than x32. I am submitting 8 patches to replace
>> long or unsigned long with __kernel_[u]long_t so that those struct types
>> can be used with x32 system calls.
>
> Independent on how this fixes things, how does the kernel_long_t name
> here make any sense?
>
> On x86-64 "kernel" long always is 64 bits wide. The userspace ABI long
> might be 32 or 64bits wide.
>
> Currently kernel_long_t has almost no uses, so it might be a good time
> to fix the name, define the rules for it, and last but not least
> properly document the intent for thse types.
>
This comment by Christoph was literally the only feedback on this
patchset. The definition of __kernel_[u]long_t is "the size of 'long'
for the native kernel for the ABI". H.J.'s patchset only affects x86
(specifically x86-64) since on all other platforms __kernel_[u]long_t is
simply defined as long/unsigned long.
That being said, x32 is not the only ABI of this type. In particular,
if the MIPS N32 and ARM64 ILP32 maintainers have suggestions which would
make this work more applicable to them, it would be highly useful to
receive any such feedback.
-hpa
next prev parent reply other threads:[~2014-01-20 17:47 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-27 22:14 [PATCH 0/8] Update kernel uabi header files for x32 H.J. Lu
2013-12-27 22:14 ` [PATCH 1/8] Use __kernel_long_t in struct timex H.J. Lu
2014-01-21 5:15 ` [tip:x86/x32] uapi: " tip-bot for H.J. Lu
2013-12-27 22:14 ` [PATCH 2/8] Use __kernel_long_t/__kernel_ulong_t in <linux/resource.h> H.J. Lu
2014-01-21 5:15 ` [tip:x86/x32] uapi: Use __kernel_long_t/__kernel_ulong_t in < linux/resource.h> tip-bot for H.J. Lu
2013-12-27 22:14 ` [PATCH 3/8] Use __kernel_ulong_t in uapi struct ipc64_perm H.J. Lu
2014-01-21 5:15 ` [tip:x86/x32] uapi, asm-generic: " tip-bot for H.J. Lu
2013-12-27 22:14 ` [PATCH 4/8] Use __kernel_long_t in struct msgbuf H.J. Lu
2014-01-21 5:16 ` [tip:x86/x32] uapi: " tip-bot for H.J. Lu
2013-12-27 22:14 ` [PATCH 5/8] Use __kernel_ulong_t in struct msqid64_ds H.J. Lu
2014-01-21 5:16 ` [tip:x86/x32] uapi: " tip-bot for H.J. Lu
2013-12-27 22:14 ` [PATCH 6/8] Use __kernel_ulong_t in x86 struct semid64_ds H.J. Lu
2014-01-21 5:16 ` [tip:x86/x32] x86, uapi, x32: " tip-bot for H.J. Lu
2013-12-27 22:14 ` [PATCH 7/8] Use __kernel_ulong_t in shmid64_ds/shminfo64/shm_info H.J. Lu
2014-01-21 5:16 ` [tip:x86/x32] uapi: Use __kernel_ulong_t in shmid64_ds/shminfo64/ shm_info tip-bot for H.J. Lu
2013-12-27 22:14 ` [PATCH 8/8] Use __kernel_long_t in struct mq_attr H.J. Lu
2014-01-21 5:16 ` [tip:x86/x32] uapi: " tip-bot for H.J. Lu
2015-11-24 4:39 ` [PATCH 8/8] " Dmitry V. Levin
2013-12-28 16:33 ` [PATCH 0/8] Update kernel uabi header files for x32 Christoph Hellwig
2013-12-28 17:01 ` H. Peter Anvin
2014-01-20 17:46 ` H. Peter Anvin [this message]
2014-01-20 17:50 ` Christoph Hellwig
2014-01-20 17:51 ` H.J. Lu
2014-01-20 17:52 ` H.J. Lu
2014-01-20 17:52 ` H. Peter Anvin
2014-01-20 17:52 ` H. Peter Anvin
2014-01-21 12:04 ` Catalin Marinas
2014-01-21 12:22 ` H.J. Lu
2014-01-21 15:43 ` H. Peter Anvin
2014-01-21 17:06 ` H. Peter Anvin
2014-01-22 15:10 ` Catalin Marinas
-- strict thread matches above, loose matches on Subject: below --
2013-12-27 17:25 H.J. Lu
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=52DD6101.4010708@zytor.com \
--to=hpa@zytor.com \
--cc=catalin.marinas@arm.com \
--cc=hch@infradead.org \
--cc=hjl.tools@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ralf@linux-mips.org \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
/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).