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 939DBC43444 for ; Thu, 17 Jan 2019 11:17:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 60F412054F for ; Thu, 17 Jan 2019 11:17:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="M6ExSUpc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727215AbfAQLRV (ORCPT ); Thu, 17 Jan 2019 06:17:21 -0500 Received: from mail-yb1-f193.google.com ([209.85.219.193]:45046 "EHLO mail-yb1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726739AbfAQLRV (ORCPT ); Thu, 17 Jan 2019 06:17:21 -0500 Received: by mail-yb1-f193.google.com with SMTP id e1so2842468ybn.11; Thu, 17 Jan 2019 03:17:20 -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=wZ2GuwWDIQMfB01jHC2NUe5cfv/zf2jiavgK6wDkhWM=; b=M6ExSUpcObxmPbJfy2CWDsCJnUTA4ifxfnR9abdtsrPDmVZi3E7TeihflQTwuCGgtb 3HPyXl6pUjWGqUEsqlQq1vANgxY766O8YEVqptFb9M20ijX8jkB2qBEp58ounziKy6Pu 635XGYMVsvnT0W+2JaVti97LRCugRMmxmIcMSjqDcWqx7OVZRWFQvbYXKrUa/ZpkSaIK EOFlVmpcToDWkz/GMmQtqj6mHnNLe0RhhnUeZdSpjdWaZzLH0k7pXmP/1z/nPKCgpqPW Xv99DY+wiati1lgpgB3+rU5a43aEs0pUdfSr6oLaNsvfYKybYL5Lhaf4OXKoQD9Z1LFI 4fuw== 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=wZ2GuwWDIQMfB01jHC2NUe5cfv/zf2jiavgK6wDkhWM=; b=hCAdfCSnq6UMzKL0efelCR3N0nInSUc61dlmhEP6crIRDO5XbHYK0aIpabtLjvvQhV 0pWrCAs8gWrKRgL8rHm2H1VUaCbZ1fy8Z62+YfF/O2bWAIyZcv3s8GJGLSqYP6XluYEX ISGP4uEt+fOQGIGEV5byUepn7f3BJEg8TFAN1BcJFVkbD5nztm868OyUV11tsky5sNci Hz/r/iFyQNS2EYYfo5tHBSmwfsyQBozfpnEqeB2404eJ0jzy8rftVZcQ7robaGT+JY9g krrX4eg8vwblbyM+0pLSZ+XW/J++cSt9oS51nnO/VBYqyExq3oNXF44fMqanNhq2rv78 yo7Q== X-Gm-Message-State: AJcUukffvKBEkVEXi5cSRN7t8g4GnC7/r7IrdaXXjG0IU66wsmiCNOXL y9Y6mCSkzjyViKhkURTFIQiTAUD2IhGx/1sTckI= X-Google-Smtp-Source: ALg8bN7IK1eZA65psVDCCLr+e7BsXCcDviSEofWF2836ZnQGfVlKoMPBwtK5YttzGLtqtQseR7TZYIZRqe+ykAiPqkU= X-Received: by 2002:a25:a28e:: with SMTP id c14mr1385025ybi.462.1547723840168; Thu, 17 Jan 2019 03:17:20 -0800 (PST) MIME-Version: 1.0 References: <20190102174736.GB29127@quack2.suse.cz> <20190108100500.GA15801@quack2.suse.cz> <20190115092414.GA4138@quack2.suse.cz> <20190115180156.GB6310@bombadil.infradead.org> <20190116120754.GF26069@quack2.suse.cz> <20190116165147.GI26069@quack2.suse.cz> <20190117093555.GC9378@quack2.suse.cz> In-Reply-To: <20190117093555.GC9378@quack2.suse.cz> From: Amir Goldstein Date: Thu, 17 Jan 2019 13:17:08 +0200 Message-ID: Subject: Re: [GIT PULL] dtype handling cleanup for v4.21-rc1 To: Phillip Potter Cc: Jan Kara , Linus Torvalds , "cc: Matthew Wilcox" , linux-fsdevel , Ext4 , Al Viro 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 Thu, Jan 17, 2019 at 11:35 AM Jan Kara wrote: > > On Wed 16-01-19 18:56:17, Amir Goldstein wrote: > > On Wed, Jan 16, 2019 at 6:51 PM Jan Kara wrote: > > > > > > On Wed 16-01-19 16:34:36, Phillip Potter wrote: > > > > Dear Jan, > > > > > > > > I am happy to rework the patches, all fair comment. Slight problem > > > > being my computer is in a box right now as I've just moved house. I > > > > will get this done in the next few days if that's ok? > > > > > > Sure, no problem. Patches won't make it in this release cycle so we have > > > like three weeks to get them ready for the next merge window. > > > > > > > Also, and Jan will correct me if I am wrong. > > I think that reworking only the common and ext2 patches would > > be sufficient for this cycle. > > Yes, that's also true. > > > You can prepare the rest of the patches for next cycle after > > the common patch has landed. > > Correct, since the plan is for these to land through other maintainers' > trees. But still it would be nice if we had them earlier just to see of > other maintainers don't seriously oppose the idea. To that end it is > probably good to reference the discussion with Linus in the cover letter > and the email with common infrastructure, explaining why converting to > common defines instead of keeping filesystem specific ones was done. > Phillip, While I see no problem with Linus' proposal to get rid of EXT2_FT_* completely. That may be practical for EXOFS_FT_*, F2FS_FT_*, ... But some fs maintainers may prefer to define (not re-define) the fs specific constants, e.g.: #define EXT4_FT_DIR FT_DIR If for no other reason, it will result in slightly less code churn. However, note that you may NOT get rid of defines in uapi headers: BTRFS_FT_*, NILFS_FT_* and defining them to the common constant will require exporting common constants to uapi headers. That is one mess you do not want to get yourself into. So I'm afraid for btrfs/nilfs, the "disgusting" BUILD_BUG_ON() statements in the only practical outlet if they want to use the common conversions code. If you prepare the patch series with several options as described above (choose one option per fs), then later maintainers can use either option when applying the individual patches. Thanks, Amir.