From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f66.google.com ([209.85.221.66]:41464 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725994AbeJYEUg (ORCPT ); Thu, 25 Oct 2018 00:20:36 -0400 Received: by mail-wr1-f66.google.com with SMTP id q7-v6so6862630wrr.8 for ; Wed, 24 Oct 2018 12:51:11 -0700 (PDT) Date: Wed, 24 Oct 2018 20:51:08 +0100 From: Phillip Potter To: Amir Goldstein 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 Message-ID: <20181024195108.GA30124@pathfinder> References: <20181023201953.GA15687@pathfinder> <20181024130206.GC11606@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 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