From: Theodore Ts'o <tytso@mit.edu>
To: Dave Chinner <david@fromorbit.com>
Cc: Andreas Dilger <adilger@dilger.ca>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Aurelien Jarno <aurelien@aurel32.net>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Robert Edmonds <edmonds@debian.org>,
Rob Browning <rlb@defaultvalue.org>
Subject: Re: Argument type for FS_IOC_GETFLAGS/FS_IOC_SETFLAGS ioctls
Date: Sun, 1 Dec 2013 23:52:32 -0500 [thread overview]
Message-ID: <20131202045232.GA25294@thunk.org> (raw)
In-Reply-To: <20131201222003.GX10988@dastard>
On Mon, Dec 02, 2013 at 09:20:03AM +1100, Dave Chinner wrote:
> Ugh, that'll just screw it up even more. And if we put the ~10 XFS
> flags in there that aren't supported by FS_IOC_GETFLAGS, and all the
> others from other filesystems, we'll be out of space in a couple of
> kernel releases...
What are the definitions XFS flags, and how is XFS currently
setting/getting them, out of curiosity?
> And FWIW, an attribute based approach means you don't need to get
> the flags before setting them to ensure you don't reset flags you
> don't care about, so it's safer from that perspective, too...
Sure, but it will also be more complex, since we'll now have to parse
a whole series of strings and translate them into flags. ... and then
the m68k and other small device folks will start kvetching about how
the kernel gets bigger with every release, and how their poor
bootlader doesn't support kernels bigger than some arbitrary limit.
> > The options and opportunities for bike shedding are endless. :-)
>
> I'm not interested in bike shedding - let's just solve the problem
> once and for all....
I'm curious what the XFS flags are because it's not clear to me
whether the total number of file system attributes that would be
legitimately fs generic are in the dozens, hundreds, or thousands.
There is such a thing as overdesign.
Regards,
- Ted
next prev parent reply other threads:[~2013-12-02 4:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-26 20:05 Argument type for FS_IOC_GETFLAGS/FS_IOC_SETFLAGS ioctls Aurelien Jarno
2013-11-27 1:01 ` Darrick J. Wong
2013-11-27 4:00 ` Theodore Ts'o
2013-11-27 10:03 ` Aurelien Jarno
2013-11-27 13:34 ` Theodore Ts'o
2013-11-27 18:14 ` Robert Edmonds
2013-11-27 23:14 ` Aurelien Jarno
2013-11-29 0:53 ` Andreas Dilger
2013-11-29 4:54 ` Theodore Ts'o
2013-11-29 5:27 ` Dave Chinner
2013-11-29 14:22 ` Theodore Ts'o
2013-11-29 16:32 ` Rob Browning
2013-12-01 22:20 ` Dave Chinner
2013-12-02 4:52 ` Theodore Ts'o [this message]
2013-12-02 22:30 ` Dave Chinner
2013-11-29 21:55 ` Andreas Dilger
2013-12-19 18:20 ` Rob Browning
2013-12-19 23:30 ` Darrick J. Wong
2013-11-27 10:15 ` Christoph Hellwig
2014-06-30 22:51 ` Rob Browning
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=20131202045232.GA25294@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=aurelien@aurel32.net \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=edmonds@debian.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=rlb@defaultvalue.org \
--cc=viro@zeniv.linux.org.uk \
/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).