On Nov 26, 2013, at 9:00 PM, Theodore Ts'o <tytso@xxxxxxx> wrote:
> Yes, it's unfortunate that programs that programs that try to use a
> long are breaking on 64-bit big endian machines, but (a) there are
> much fewer of them, and (b) they are only breaking on big endian
> machines, as opposed the much bigger class of userspace programs which
> would break on the proposed change for ALL 64-bit platforms, including
> x86-64. And like it or not, there are a lot more linux machines
> running x86-64, compared to those running linux on big-endian PowerPC.
> (Of course, the little-endian ppc machines which IBM is now pushing
> for Linux in data centers will be just fine. :-P)
>
> If people really cared, we could allocate a new ioctl codepoint, and
> then teach the kernel to support the new ioctl number, and then
> gradually change userspace to first try the new ioctl, and if that
> failed go back to the old one. The coversion progress would take 5-10
> years (there are still sites running RHEL 3, and RHEL 4 after all),
> and it wouldn't help existing userspace programs, that would still be
> using the old code point. Hence my recommendation that the path of
> least resistence is to fix the kernel FUSE code, instead of trying to
> change the world.
Note that there are already FS_IOC32_{GET,SET}{VERSION,FLAGS} ioctl
definitions for that date back to 2.6.19 or so that correctly use "int"
for the size argument. Those are unfortunately(?) under CONFIG_COMPAT
instead of just being inline with the normal ioctl definitions, so I'm
not sure if those are available on the systems in question. CONFIG_COMPAT
was the default for RHEL5 and SLES10 kernels, but the compat ioctl code
was only in ext4 and not ext3 in RHEL5 at least.
I suspect those have already been around long enough for chattr/lsattr to
start trying to use them first, and fall back to using the "broken" IOC
numbers if they fail.
There also are new definitions for EXT[34]_IOC_GETVERSION since pre-git times
(vs. the FS_IOC_GETVERSION == EXT[34]_IOC_GETVERSION_OLD definition) that moves
these IOC numbers out of the 'v' space into the 'f' space to avoid potential
conflicts with other users of the 'v' space. It is unfortunate that the
adoption of FS_IOC_GETVERSION used the old definition instead of the new
one, since non-ext3/4 filesystems do not implement the new IOC number and
would push adoption back another handful of years.
> P.S. If we were going to create a new ioctl, what I'd suggest is that
> the new ioctl explicitly use a 64-bit type, instead of using "long" or
> "int", to avoid the compat ioctl hair to allow 64-bit kernels to
> support 32-bit userspace programs.
Unfortunately, I don't think it would be possible to just use:
#define FS_IOC_GETFLAGS_NEW _IOR('f', 1, __u64)
since this would conflict with the existing "long" definition on 64-bit
platforms that actually expect an "int" argument. It definitely would
be desirable to get a 64-bit attributes API, since we are very close to
running out of space in the 32-bit flags definitions.
Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
