From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aserp1050.oracle.com ([141.146.126.70]:25467 "EHLO aserp1050.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752097AbdBHS5h (ORCPT ); Wed, 8 Feb 2017 13:57:37 -0500 Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by aserp1050.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v18Iue00018452 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 8 Feb 2017 18:56:41 GMT Date: Wed, 8 Feb 2017 10:55:26 -0800 From: "Darrick J. Wong" To: "Theodore Ts'o" Cc: Anand Jain , Eric Biggers , Eric Biggers , linux-fsdevel , Joe Richey Subject: Re: fs/crypt ioctl and attr Message-ID: <20170208185526.GG10498@birch.djwong.org> References: <658bd54a-ff84-3e15-872d-10b60740729f@oracle.com> <20170206233122.GA60086@google.com> <87923051-07a5-bb89-236f-5e491c0249f3@oracle.com> <20170207073426.GB2244@zzz> <89878676-70a7-008c-64d1-937404411722@oracle.com> <20170208024100.gp7nenim4fqf2kg5@thunk.org> <20170208043613.GF10498@birch.djwong.org> <20170208142127.ih65akei4q44iqa7@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170208142127.ih65akei4q44iqa7@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Feb 08, 2017 at 09:21:27AM -0500, Theodore Ts'o wrote: > On Tue, Feb 07, 2017 at 08:36:13PM -0800, Darrick J. Wong wrote: > > As one of 'those people', I think I'm well qualified to say that a fake > > xattr having side effects that doesn't behave in quite the same ways as > > regular xattrs is setting up other programs (the ones that listxattr all > > the attrs and getxattrs them) for all kinds of weird yuckiness. And by > > 'weird yuckiness' I mean "this one magic xattr returned EOPNOTSUPP and > > the whole backup program exploded". > > > > Now granted you can argue that we're just shifting that into an ioctl, > > but ioctls are already weird and yucky. :) > > If we were going to do anything at all, it would be to move it to a > syscall. But given that it took ***years*** for the glibc developers > to get around to adding getrandom(2) to glibc, we'd be stuck using the > syscall(3) interface and having to deal with different syscall numbers > for different architectures (in case we're compiling on a system which > hadn't update the kernel headers in /usr/include), and so at least in > the short term it would actually be worse than using ioctl's. > > For similar reasons I don't think there's going to be that much > interest in adding a syscall to replace XFS_IOC_GOINGDOWN. We'll > probably go with FS_IOC_GOINGDOWN, just as we have with > FS_IOC_SETFLAGS, etc. > > Speaking of XFS_IOC_GOINGDOWN, I'm sure the name was coined many, many > years agoo, back when concerns such as "avoiding a hostile working > environment" were much of an issue. Even so, I note that *someone* > decided that the name that should be exposed to customer (in the > xfs_io man page), was "shutdown", and not "goingdown". So is there > any objection if we use the name FS_IOC_SHUTDOWN moving forward? None here. I think Dave asked for GOINGDOWN -> SHUTDOWN too. > Some might accuse us of being overly concerned about political > correctness, but I have to admit I did have a slight twinge when I > checked in the ext4 shutdown changes into our internal kernel. I was > worried that there might be some folks who might have found the name > at least a tiny bit offensive. (Not that anyone complained, but I'd > much rather be conservative in what we send, and liberal in what we > accept.) Yes, and I further argue that io control command (ioctl) names should be imperative. One doesn't yell 'going down!' to turn off the light switches. :P --D > > - Ted > > > > > > > > > > >