linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phillip Potter <phil@philpotter.co.uk>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: viro@zeniv.linux.org.uk, amir73il@gmail.com,
	linux-fsdevel@vger.kernel.org
Subject: Re: [RFC][PATCH v3 01/10] fs: common implementation of file type
Date: Wed, 24 Oct 2018 14:39:32 +0100	[thread overview]
Message-ID: <20181024133932.GD23398@pathfinder> (raw)
In-Reply-To: <20181024130206.GC11606@thunk.org>

On Wed, Oct 24, 2018 at 09:02:06AM -0400, Theodore Y. Ts'o wrote:
> On Tue, Oct 23, 2018 at 09:19:53PM +0100, Phillip Potter wrote:
> > diff --git a/include/linux/file_type.h b/include/linux/file_type.h
> 
> Shouldn't this be in include/uapi/linux/fs_types.h?
> 
> One of things which must be made crystal clear is these definitions
> MUST NOT ever change.  It would break the Userspace ABI, and would
> break file systems on-disk format.
> 
> It might also be useful to be clear *why* we are making this change in
> the first place.  Code refactorization is good from a code maintenance
> perspective (either to fix bugs, although this code is pretty
> trivial), or to make it easier to make changes in a single central
> place (which MUST NOT) happen, or to make the compiled code more
> compact.
> 
> So some documentation of how much text is actually saved might be
> worthwhile.
> 
> 						- Ted

Dear Ted,

Regarding location of the additional header, thank you for this
suggestion - I will move it.

As for making it extra clear that the definitions must not change, I
will add this to the comment at the beginning of the file, and also
in the intro message of the new series I am about to publish.

I can't speak for Amir, but regarding why I think this would be a
good change, my thought process is that it would make adding new
file systems that use these on-disk type layouts in future more
easy, as the central generic implementation can be used rather than
copying and pasting and changing names etc. as needed, which is
more error prone. I am happy to add more documentation in this regard,
and also mention savings where appropriate.

Regards,
Phil

  reply	other threads:[~2018-10-24 22:07 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-23 20:19 [RFC][PATCH v3 01/10] fs: common implementation of file type Phillip Potter
2018-10-24  6:16 ` Amir Goldstein
2018-10-24  8:21   ` Phillip Potter
2018-10-24  9:20     ` Amir Goldstein
2018-10-24  9:31       ` Phillip Potter
2018-10-24  9:44         ` Amir Goldstein
2018-10-24  9:56           ` Phillip Potter
2018-10-24 10:06             ` Amir Goldstein
2018-10-26 14:45   ` Phillip Potter
2018-10-24 12:37 ` Al Viro
2018-10-24 13:33   ` Phillip Potter
2018-10-24 13:02 ` Theodore Y. Ts'o
2018-10-24 13:39   ` Phillip Potter [this message]
2018-10-24 14:41   ` Amir Goldstein
2018-10-24 19:51     ` Phillip Potter
2018-10-25 11:20 ` Jan Kara
2018-10-25 12:56   ` Phillip Potter
2018-10-25 13:42     ` Jan Kara
2018-10-25 14:24       ` Phillip Potter
  -- strict thread matches above, loose matches on Subject: below --
2018-10-27  0:53 Phillip Potter

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=20181024133932.GD23398@pathfinder \
    --to=phil@philpotter.co.uk \
    --cc=amir73il@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --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).