From: Phillip Potter <phil@philpotter.co.uk>
To: Amir Goldstein <amir73il@gmail.com>
Cc: tytso@mit.edu, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC][PATCH v3 01/10] fs: common implementation of file type
Date: Wed, 24 Oct 2018 20:51:08 +0100 [thread overview]
Message-ID: <20181024195108.GA30124@pathfinder> (raw)
In-Reply-To: <CAOQ4uxhGGZv52Ch2NjxOFt35KsFpja=jCk-x8jBNZcxRe9OoYA@mail.gmail.com>
On Wed, Oct 24, 2018 at 05:41:15PM +0300, Amir Goldstein wrote:
> On Wed, Oct 24, 2018 at 4:02 PM Theodore Y. Ts'o <tytso@mit.edu> 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?
> >
>
> IDGI. Why do we want this file in uapi?
> The DT_ constants are already defined by glibc dirent.h
> and the FT_ constants and macros we don't want to expose
> to uapi at all. Right?
>
> Maybe all we need is a comment above DT_ constants
> that those are defined by POSIX and in glibc dirent.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),
>
> Very trivial code that has had an out of bounds access bug for two
> decades and bug was duplicated to 7 filesystems. IMO, fixing the bug in
> one place instead of 7 is a good enough reason for re-factoring.
>
> Thanks,
> Amir.
Dear Amir,
Regarding the location of the extra header file, I'm happy to stick it
in either include/linux or include/uapi/linux before sending out the
revised series. You make a valid point about the FT_ constants and macros
being kernel only though, so perhaps the comment is a better option? I
will wait a bit before sending out as I'm interested to see what Ted thinks.
Many thanks.
Regards,
Phil
next prev parent reply other threads:[~2018-10-25 4:20 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
2018-10-24 14:41 ` Amir Goldstein
2018-10-24 19:51 ` Phillip Potter [this message]
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=20181024195108.GA30124@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.