From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Anand Jain <anand.jain@oracle.com>,
Eric Biggers <ebiggers3@gmail.com>,
Eric Biggers <ebiggers@google.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Joe Richey <joerichey@google.com>
Subject: Re: fs/crypt ioctl and attr
Date: Wed, 8 Feb 2017 10:55:26 -0800 [thread overview]
Message-ID: <20170208185526.GG10498@birch.djwong.org> (raw)
In-Reply-To: <20170208142127.ih65akei4q44iqa7@thunk.org>
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
>
>
>
>
>
>
>
>
>
>
>
prev parent reply other threads:[~2017-02-08 18:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-06 23:19 fs/crypt ioctl and attr Anand Jain
2017-02-06 23:31 ` Eric Biggers
2017-02-07 5:55 ` Anand Jain
2017-02-07 7:34 ` Eric Biggers
2017-02-07 9:52 ` Anand Jain
2017-02-08 2:41 ` Theodore Ts'o
2017-02-08 4:36 ` Darrick J. Wong
2017-02-08 14:21 ` Theodore Ts'o
2017-02-08 18:55 ` Darrick J. Wong [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170208185526.GG10498@birch.djwong.org \
--to=darrick.wong@oracle.com \
--cc=anand.jain@oracle.com \
--cc=ebiggers3@gmail.com \
--cc=ebiggers@google.com \
--cc=joerichey@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).