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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 44765FA3729 for ; Mon, 21 Jan 2019 11:22:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 15B0320663 for ; Mon, 21 Jan 2019 11:22:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hNLFyBmB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727776AbfAULWw (ORCPT ); Mon, 21 Jan 2019 06:22:52 -0500 Received: from mail-yb1-f194.google.com ([209.85.219.194]:42672 "EHLO mail-yb1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727720AbfAULWR (ORCPT ); Mon, 21 Jan 2019 06:22:17 -0500 Received: by mail-yb1-f194.google.com with SMTP id q145so7012799ybq.9 for ; Mon, 21 Jan 2019 03:22:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B8NucLlUrke1RT5TZPZGfM2as46PDgQQRuNtkNqKm3E=; b=hNLFyBmBTzdAA2O1MGNc+BiPXCBcuwdI5J0GGdQUa6HhdSCYk99I9dkx7/dsx22aRS Ed0NabXGCkfPxXlCMRITns8VFnVzlWN10vuaB4QPit9eGn9C3jqnn8y9HFGfEaAl/7BD QwRFgnDRqVgjOLZa5xxZeLPjQ0x/co2QTTGnjauL0zR6StJO+BB01JUfQELXY8na5iSt YMvf4U4/7mTOl+MR4+WY1RcVy3JgvLp5fd1Hf/1sx4MChZHrxLr2D4aBzB9u2lpsuL3g 5JDOPC8NzCOXMmhx7WSZk7ziqbfFIKc9K+Pha3jRh9O8Xr0JbOzreDXtagYL7ryHoabB +muQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B8NucLlUrke1RT5TZPZGfM2as46PDgQQRuNtkNqKm3E=; b=ITGY2SiSXE/f69uweP56gbAiKMHrBhHLtutWJkc1ywshSQunqIwCKBBIZGo3HHTC35 FpAa/NnChuWJI67M5KNFUW3EQaX7OsTl52sOMFEfkTguTvRukfovXc3l6+2fIfeGHOFI m9aQrZUieVJu6BH9cHST9aSj0IbGhIh8GOC4qfxe2cIzviu5+iT9E7rntVkMQ0RIN/hv 2aiBYmFe1LyAXhd3z95QM14wHB7oCify5or2NP+v1iy351XqNQPNdvy+uaYvciDS3ntR HRZRjMVIMUr26t6FwvFdRA2tUOcRyktIy4NfME5jz7/XHZovjuyOnasticWPaPRCuvB3 oooQ== X-Gm-Message-State: AJcUukfrZvSfvgIvX7Zowh6eYW7XKqQButsnmGhFUsJeVb83Tn88LHGG VC+gmSQXK3VfPi/RPctFTWeo7NM9Gnn7KgJowAo= X-Google-Smtp-Source: ALg8bN57b0QZkTr076SM5rBgYLmqT9Yd3gBKgGOihdRGEgJ/4+4tcC7q7iXrpmsJjQQWZXylXOdMORZENuH4xyh5oOs= X-Received: by 2002:a25:8003:: with SMTP id m3mr1919605ybk.337.1548069735932; Mon, 21 Jan 2019 03:22:15 -0800 (PST) MIME-Version: 1.0 References: <20190121005425.GA32315@pathfinder> <20190121093510.GA11365@bombadil.infradead.org> In-Reply-To: <20190121093510.GA11365@bombadil.infradead.org> From: Amir Goldstein Date: Mon, 21 Jan 2019 13:22:05 +0200 Message-ID: Subject: Re: [RFC][PATCH v5 00/09] common implementation of dirent file types To: Matthew Wilcox Cc: Phillip Potter , Al Viro , Jan Kara , linux-fsdevel Content-Type: text/plain; charset="UTF-8" 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 11:35 AM 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. That's a good point, but I think we should let btrfs developers choose where and how to change the definitions. Probably the ext4 example (patch 7) would be the best to follow, as btrfs also uses some non common constants (BTRFS_FT_MAX, BTRFS_FT_XATTR) that do not map to the common DT_* values. Thanks, Amir.