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@xxxxxxxxxxxxxxxxxx> 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... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
