From: David Daney <ddaney.cavm@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, "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 01/10] Use __kernel_long_t in struct timex
Date: Thu, 17 May 2012 16:51:17 -0700 [thread overview]
Message-ID: <4FB58EF5.2090306@gmail.com> (raw)
In-Reply-To: <CA+55aFxAY5FvJOjr9=W=g7WDj_gNwKrEeCFAiY2L2YmpaDx1cw@mail.gmail.com>
On 05/17/2012 03:56 PM, Linus Torvalds wrote:
> On Thu, May 17, 2012 at 3:50 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> I think __word would be good too, *except* for the fact that
>> especially in x86 land, I think there's the legacy confusion with
>> "word" being 16-bit. Ugh.
>
> Looking at the x32 case, I have to say that "long" in general looks
> horrible. Especially when we have things like
>
> typedef long long __kernel_long_t;
>
> (and __long really wouldn't look any nicer). Any sane person would go
> "Eww" at looking at that - we're using 'long long' to typedef a type
> that is named 'long'.
>
> It would make much more sense to use "__word" for reasons like that.
> But I really don't think that works well in a x86 context.
>
> Other ideas? Maybe "__wordsize" would be less associated with x86 16-bit words?
>
FWIW: "__abi_wordsize" to indicate that it is not really a property of
the machine itself, but rather the ABI in use.
David Daney
next prev parent reply other threads:[~2012-05-17 23:51 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 [this message]
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
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=4FB58EF5.2090306@gmail.com \
--to=ddaney.cavm@gmail.com \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--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.