From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Ts'o Subject: Re: Argument type for FS_IOC_GETFLAGS/FS_IOC_SETFLAGS ioctls Date: Wed, 27 Nov 2013 08:34:37 -0500 Message-ID: <20131127133437.GB19941@thunk.org> References: <20131126200559.GH20559@hall.aurel32.net> <20131127010141.GA10273@birch.djwong.org> <20131127040013.GA19941@thunk.org> <20131127100347.GA20511@hall.aurel32.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Darrick J. Wong" , Alexander Viro , linux-fsdevel@vger.kernel.org, Robert Edmonds , Rob Browning To: Aurelien Jarno Return-path: Received: from imap.thunk.org ([74.207.234.97]:34107 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751241Ab3K0Nes (ORCPT ); Wed, 27 Nov 2013 08:34:48 -0500 Content-Disposition: inline In-Reply-To: <20131127100347.GA20511@hall.aurel32.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Nov 27, 2013 at 11:03:47AM +0100, Aurelien Jarno wrote: > In my case, I am *not* talking about FUSE code, but programs using this > ioctl from userland. Changing the kernel FUSE code won't fix the problem > I reported. I wasn't aware of the fact that there were broken userspace programs up until now --- and things have like this for well over a decade, with no one complaining until now, which gives you a hint about how prevelant this problem actually is. > People who do the things correctly lookup the argument type in > , they see it's a long and then use a long in their code. And > they are right. The bare minimum would be to add a comment close to the > definition to explain to use an int and not a long. The documentation is specifies the FS_IOC_GETFLAGS and FS_IOC_SETFLAGS takes an int * and int, respectively, in the ioctl_list man page. As far as the "self documenting" ioctl numbering is concerned, I've always considered it "mostly harmless", but never as authoratative documentation. Hence, trying to use words such as "right" or "wrong" is not particularly interested as far as I'm concerned. (I'm reminded of the story of the time when Richard Stallman blindly steped into the crosswalk, and was almost killed by a car running the red light. Someone held him back and said, "didn't you see that car? He would have almost killed you!". To which Richard said, "but he would have been in the wrong.") In any case, sure, we can add a documentation to the header file in the kernel sources, and the glibc folks will need to be asked to fix up /usr/include/linux/fs.h (which is not the same as the include/linux/fs.h in the kernel). But it doesn't change the fact that it is bup and libexplain that will need to be changed, regardless of whether they were in the "right" or in the "wrong". If the sense of moral superiority makes them more willing to fix their code, fine. Regards, - Ted