linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	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: Sat, 19 May 2012 15:35:19 +0100	[thread overview]
Message-ID: <20120519143519.GA11775@ZenIV.linux.org.uk> (raw)
In-Reply-To: <201205190756.30492.arnd@arndb.de>

On Sat, May 19, 2012 at 07:56:30AM +0000, Arnd Bergmann wrote:

> * __kernel_time_t is not the only type that differs between 32 and 64
>   bit platforms: the structures also include a __kernel_mode_t, which
>   is different between 32/64 bit on at least s390, x86, arm and sparc.

... and said __kernel_mode_t needs to die.  Along with all remaining
instances of mode_t kernel-side.

BTW, ncp_mount_data (i.e. ncp mount with version less than 4) needs to be
added to feature-removal-schedule.txt.  That'll bury one of the few places
where we have that crap in public headers.

And no, assorted struct stat do not need that thing at all.  They should
use explicit types, TYVM.

BTW, why do we have __kernel_uid32_t?  As an invitation for some architecture
to come up with 64bit "32bit UID" type?  What's wrong with __u32, or
at least moving the default (== only, fortunately) definitions to
linux/posix_types.h and making them unconditional?  Same for gid32_t
stuff, of course...

__kernel_nlink_t is also a bad idea (and an invitation to bugs in the kernel,
while we are at it).  BTW, now that I look at it...  ulong_t as default is
also wrong; there's no point making the internal nlink_t different on different
platforms.  Fortunately, that one is really easy to kill; mips/parisc/ppc
stat.h instances switch to corresponding explictly-sized types, at which point
nothing in userland needs to see it and we can simply switch nlink_t
kernel-side to __u32 and be done with that...

  reply	other threads:[~2012-05-19 14:35 UTC|newest]

Thread overview: 77+ 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 ` 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:13   ` 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         ` 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   ` 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   ` 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   ` 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   ` 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 22:13   ` H.J. Lu
2012-05-17 23:51   ` H. Peter Anvin
2012-05-18  0:07     ` Linus Torvalds
2012-05-18  0:07       ` Linus Torvalds
2012-05-18  0:14       ` H. Peter Anvin
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 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 [this message]
2012-05-18 11:44           ` David Howells
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  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  1:32                         ` H.J. Lu
2012-05-20  2:08                         ` H. Peter Anvin
2012-05-20  2:08                           ` H. Peter Anvin
2012-05-18  3:56           ` H.J. Lu
2012-05-18 21:06             ` H. Peter Anvin
2012-05-18 11:53           ` David Howells
2012-05-18 12:06             ` H.J. Lu
2012-05-18 12:06               ` H.J. Lu
2012-05-17 22:13 ` [PATCH 09/10] Use __kernel_ulong_t in struct ipc64_perm H.J. Lu
2012-05-17 22:13   ` 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: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=20120519143519.GA11775@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=arnd@arndb.de \
    --cc=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=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 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).