From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [PATCH] vfs: move ACL cache lookup into generic code
Date: Sat, 23 Jul 2011 22:53:37 +0100
Message-ID: <20110723215337.GK24703@ZenIV.linux.org.uk>
References: <alpine.LFD.2.02.1107221038090.29055@i5.linux-foundation.org>
 <alpine.LFD.2.02.1107221932120.27112@i5.linux-foundation.org>
 <20110723032944.GA24703@ZenIV.linux.org.uk>
 <20110723074722.GD24703@ZenIV.linux.org.uk>
 <20110723145037.GA10213@lst.de>
 <20110723153200.GF24703@ZenIV.linux.org.uk>
 <20110723170216.GI24703@ZenIV.linux.org.uk>
 <CA+55aFwsLHNJYYV=G5QFFYXHGrvutVw1oSWw_wK=HDX6jYm06A@mail.gmail.com>
 <20110723182029.GJ24703@ZenIV.linux.org.uk>
 <CA+55aFxh-VQQWFS=ZMv9Cx36kZtUA+z9cnrnshi5A8gB84u7Lw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Christoph Hellwig <hch@lst.de>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:55476 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751374Ab1GWVxl (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Sat, 23 Jul 2011 17:53:41 -0400
Content-Disposition: inline
In-Reply-To: <CA+55aFxh-VQQWFS=ZMv9Cx36kZtUA+z9cnrnshi5A8gB84u7Lw@mail.gmail.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Sat, Jul 23, 2011 at 11:29:39AM -0700, Linus Torvalds wrote:
> On Sat, Jul 23, 2011 at 11:20 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >>
> >> but we'll never do it, because it's such a pain.
> >
> > Maybe, maybe not... ?There's not *that* many of users of either of those.
> 
> The problem is that current 'mode_t' and if it is ever exported to
> user space (and I bet it is, in various structures), we're basically
> screwed. You have a random architecture-specific size, that you can't
> clean up to be the size you actually _use_, because it's now part of
> the ABI.

It's not that bad, really.  On part of targets struct stat has mode_t st_mode;
same for hpux_stat64 and ipc64_perm on parisc and stat64 on mips.  Other
just declare st_mode as unsigned int or unsigned short without any problems
(including x86, FWIW).  There's also __kernel_mode_t, which is arch-dependent;
not sure if it's always the same as what's used for st_mode in struct stat.
That's often used for ipc64_perm (->mode) and (AFAICS, always) for ipc_perm
(->mode, again).

We also have a few syscalls passing mode_t - chmod, fchmod, fchmodat,
mq_open.  open(), mknod() and mkdir() use int.

	That's about it - shouldn't be a problem to switch mode_t in ABI to
__kernel_mode_t (equivalent, since mode_t is typedefed to __kernel_mode_t)
and we are free to do whatever we want with internal mode_t.  I suspect
that starting with centralized typedef for umode_t (always u16) it wouldn't
take much to drive all internal uses to umode_t (or size_t, in at least one
case ;-), then replace all remaining (part of ABI) instances with
__kernel_mode_t and rename umode_t to mode_t.  I'll try to put such a series
together tonight; will push to #mode_t once done...