From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: Argument type for FS_IOC_GETFLAGS/FS_IOC_SETFLAGS ioctls Date: Fri, 29 Nov 2013 14:55:54 -0700 Message-ID: <7D1C667F-72EE-4884-935B-0FE91CBD4F3E@dilger.ca> References: <20131126200559.GH20559@hall.aurel32.net> <20131127010141.GA10273@birch.djwong.org> <20131127040013.GA19941@thunk.org> <20131129045412.GA18142@thunk.org> <20131129052748.GV10988@dastard> Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: multipart/signed; boundary="Apple-Mail=_537D37D6-6A75-4F75-8060-F18A4379C146"; protocol="application/pgp-signature"; micalg=pgp-sha1 Cc: Theodore Ts'o , "Darrick J. Wong" , Aurelien Jarno , Alexander Viro , linux-fsdevel , Robert Edmonds , Rob Browning To: Dave Chinner Return-path: Received: from mail-pb0-f41.google.com ([209.85.160.41]:53894 "EHLO mail-pb0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751170Ab3LBJNt (ORCPT ); Mon, 2 Dec 2013 04:13:49 -0500 Received: by mail-pb0-f41.google.com with SMTP id jt11so18593940pbb.0 for ; Mon, 02 Dec 2013 01:13:49 -0800 (PST) In-Reply-To: <20131129052748.GV10988@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --Apple-Mail=_537D37D6-6A75-4F75-8060-F18A4379C146 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 28, 2013, at 10:27 PM, Dave Chinner wrote: > On Thu, Nov 28, 2013 at 11:54:12PM -0500, Theodore Ts'o wrote: >> On Thu, Nov 28, 2013 at 05:53:10PM -0700, Andreas Dilger wrote: >>>=20 >>> 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. >>=20 >> This were introduced to support 32-bit userspace programs (where >> sizeof(long) =3D=3D sizeof(int) =3D=3D 4) with a 64-bit kernel. The = intent >> was not to "fix" the ioctl, so much as it was to enable 32-bit >> programs. The compat code is in ext3 as well, although it uses >> EXT3_IOC32_[SG]ETFLAGS. >>=20 >>> 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. >>=20 >> Nope, chattr/lsattr does not try using them first, because the intent >> wasn't to "fix" the "broken" IOC numbers. If you look in the = sources, >> e2fsprogs is only using EXT2_IOC_[SG]ETFLAGS. (These ioctls were >> originally only defined for ext2, and intended for use only for >> ext[23]. They got adopted by other file systems, and then they get >> moved into linux/fs..) Sorry, what I meant was "the compat ioctls been around long enough that = it might make sense to modify lsattr/chattr to _start_ trying to use them = in place of the old semi-broken IOC numbers". That might make sense = regardless of whether we add a separate 64-bit IOC number, since at least the = definition won't be broken. In a few years, the old "long" IOC number could be = deprecated and FS_IOC_{GET,SET}FLAGS could be assigned to the new number so that = new apps compile to use the new number. >> Sure, I was thinking about doing something like this instead: >>=20 >> #define FS_IOC_GETFLAGS_WIDE _IOR('f', 32, __u64) >> #define FS_IOC_SETFLAGS_WIDE _IOR('f', 32, __u64) >>=20 >> And I agree that a good reason to do this is to get 64 bits worth of >> attributes.... >=20 > Why create a new ioctl for getting these generic attributes out of > the kernel? Isn't that the problem xstat() is supposed to solve? >=20 > And if it's truly generic stuff, then a syscall pair with enough > bitmap space for the forseeable future is more appropriate than a > new ioctl... I'm definitely in favour of the xstat() API, and have been for years. = It's just never managed to get accepted into the kernel despite how many = times it's been submitted. Every time it appears there is one group of people that = say "it should also do X" and another group that say "it does too much, take = Y out". Cheers, Andreas --Apple-Mail=_537D37D6-6A75-4F75-8060-F18A4379C146 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBUpxPQnKl2rkXzB/gAQI+eBAAiD9+957owpsCB7sz8+m+Z++M9kbuMi0+ CXTNpA1tpC8w6FBh1AtSsAJBKtfavXXILFZeGocrrdSFlqDFKTImKeUV4dmooTWn /+yTGoss5v990rf1uYTHQLk7Vs3UNStBfTCiWt9u396tKD1clKOmdsM91rW7hcmH UUTuFw0uBElObCm4X4VJAsxSjWVbZTxdzaikKqSgWBjEQByZ92zCMs2Bj5flaWYo PXsM6ZSpTScXyu7ph6XTdZ2Xg2DZrTTpZLBses9+jI4H9iHbNKGncDTXXbCPguha rxgQ4gu8+xdEjpX3YDEwjonO6yahnuJvkWvC1hNzCeUN/ppaGD40aKW+8gnRrdPA TArcobllnG/8aeFb6SXKHRBHXi+IoyrXAflzjth/ZqdnVrWx4f+EinyuhML+3fMz BQ2KSeRvemD1d6FyuB/OxY8xu32mDXlVpMtIa+uQVlupZ/lzCnXPM/YFYpaWdc5h RbyGPSyckchvFIoL1WMzlJOSpD0SvgVXOYxY9vnf9dNtL5iL5RxN3p7Hv0G/SwHP yUyR0YMGpet6jaSzUbCF15d6FQaGKC9cQ1ePvsEQcFeSIU023tMsMNmq78rLeTT+ 3HeuPXOSk7Dt/KPCNg5EzolRa4WugOKPhmtzO1QGIRLWtC292EjVOnabB1vYbH0N E5gD4oHYRA4= =bWcP -----END PGP SIGNATURE----- --Apple-Mail=_537D37D6-6A75-4F75-8060-F18A4379C146--