From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1A85C282C3 for ; Tue, 22 Jan 2019 09:58:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7A120218DE for ; Tue, 22 Jan 2019 09:58:36 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=philpotter-co-uk.20150623.gappssmtp.com header.i=@philpotter-co-uk.20150623.gappssmtp.com header.b="Crj890cO" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727880AbfAVJ6f (ORCPT ); Tue, 22 Jan 2019 04:58:35 -0500 Received: from mail-wm1-f68.google.com ([209.85.128.68]:35047 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727601AbfAVJ6f (ORCPT ); Tue, 22 Jan 2019 04:58:35 -0500 Received: by mail-wm1-f68.google.com with SMTP id t200so13602350wmt.0 for ; Tue, 22 Jan 2019 01:58:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=philpotter-co-uk.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=3xQZt6rddMM+rjtrwRSOi25jQiqA6TquIFE8maIK9Aw=; b=Crj890cOPbE39/gfF8JX3Nu2V7xlcmjGefmuhg4Clf4453z93Zen4uVHsaOVA60ly9 Nk3Zur/iPyyhCWkUL2zSH86gT2faS6c/IzHZRUvyPm2C+cl0oXwdcUKzsbLdBl5Gtkid 9nRS6Suqf4k3ey9gjoyeb7tAk7Q8vBHiOKluiTn3JgI1uJcXzAPV4WujXNmRXJksLOkj eOw/Dro5eoCekc3LfrUT7OkZnyMxqJfrUArDI+W0nIVXy3MnciXwA687lMjLY7XvIecT dgBJdwh/ALF7V6vSSt1wAM22evY0D7kqoEkUyqWogZX6KSrb/oJDJ2bx3HoL8A9lx0ed NNTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=3xQZt6rddMM+rjtrwRSOi25jQiqA6TquIFE8maIK9Aw=; b=iqti7W83iqenAK1oktAWSI1+FzD8a0qriv3uHwXXSL7vDrpm0gXoyJAJKvOzUEu5Pd 0oOt3GRKva0Bh6T2ujq9Fx8MIoW0sPK29DFkQiJnJbdcMx0JnZvxqzoUuVNuU/AObdfa wt1+nnOScJr55sh0LVB8mwBYhyAqXcFqPYUamNJhKDKq1OdtGoJIy0wXI9L1Cb9M80mF kCUsSCI0ETmRnNjgVgc6qSkzJpHXIn4GhulrDfEZ1bKxjzn2y56JwD7UBRnoh9xgzh/3 /+/WWeBkAJKIu3FsKf5pjWWWet41s4cD9SiYsl0iuZihW8RqdRpdqcF1wjO8qg5O/A58 hOhg== X-Gm-Message-State: AJcUukeqgh2R1+lwpeOvsrLdrWcZsJhi1HR3TBrFcXpcPgH6vsbYI7zr HhX4tjdNSSfIlq9nIK0MjxlHCg== X-Google-Smtp-Source: ALg8bN7kFuNVlJBhfpEaMGG8Kyw0FG8cadqVx6JVe2MkkTMcf4TV8dPzYZ1igbv5o/Z9v6joibqhgQ== X-Received: by 2002:a1c:9c15:: with SMTP id f21mr2822257wme.94.1548151113198; Tue, 22 Jan 2019 01:58:33 -0800 (PST) Received: from pathfinder ([90.222.17.17]) by smtp.gmail.com with ESMTPSA id t5sm56572531wmd.15.2019.01.22.01.58.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 22 Jan 2019 01:58:32 -0800 (PST) Date: Tue, 22 Jan 2019 09:58:30 +0000 From: Phillip Potter To: Matthew Wilcox Cc: viro@zeniv.linux.org.uk, jack@suse.cz, amir73il@gmail.com, linux-fsdevel@vger.kernel.org Subject: Re: [RFC][PATCH v5 00/09] common implementation of dirent file types Message-ID: <20190122095830.GA3245@pathfinder> References: <20190121005425.GA32315@pathfinder> <20190121093510.GA11365@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190121093510.GA11365@bombadil.infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Jan 21, 2019 at 01:35:10AM -0800, Matthew Wilcox wrote: > On Mon, Jan 21, 2019 at 12:54:25AM +0000, Phillip Potter wrote: > > These patches mostly no longer include compile-time checks to ensure > > the filesystem specific on-disk bits are equivalent to the common > > implementation FT_* bits, and instead op to remove the filesystem > > specific definitions entirely where possible, as a result of the > > referenced discussion above. > > > > With the ext4 patch, the EXT4_FT_* definitions are instead defined > > to be FT_*, to give less code churn with the same result (no need > > to modify fs/ext4/namei.c). Also, the nilfs2 and btrfs filesystems > > keep their filesystem specific definitions in the include/uapi/linux > > directory, so these cannot be changed trivially without breaking > > userspace. For this reason, the compile time checks remain in these > > two filesystems. > > Just because something is exposed through the uapi directory today > doesn't mean userspace actually uses it. For example, > https://codesearch.debian.net/search?q=BTRFS_FT_DIR > > The only code which uses the filetype defines is going to be code which > actually looks at a raw filesystem image. All three examples of userspace > code in Debian have their own definitions instead of using the one which > the kernel provides. Thank you for this suggestion. I will wait and then possibly refactor the last two patches of the series. Regards, Phil