Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <valdis.kletnieks@vt.edu>
To:     Dave Chinner <david@fromorbit.com>
Cc:     Christoph Hellwig <hch@infradead.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Sasha Levin <alexander.levin@microsoft.com>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
In-Reply-To: <20190901224329.GH7777@dread.disaster.area>
References: <245727.1567183359@turing-police> <20190830164503.GA12978@infradead.org> <267691.1567212516@turing-police> <20190831064616.GA13286@infradead.org> <295233.1567247121@turing-police> <20190901010721.GG7777@dread.disaster.area> <339527.1567309047@turing-police>
 <20190901224329.GH7777@dread.disaster.area>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1567379634_4251P";
         micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date:   Sun, 01 Sep 2019 19:13:54 -0400
Message-ID: <389078.1567379634@turing-police>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--==_Exmh_1567379634_4251P
Content-Type: text/plain; charset=us-ascii

On Mon, 02 Sep 2019 08:43:29 +1000, Dave Chinner said:

> I don't know the details of the exfat spec or the code to know what
> the best approach is. I've worked fairly closely with Christoph for
> more than a decade - you need to think about what he says rather
> than /how he says it/ because there's a lot of thought and knowledge
> behind his reasoning. Hence if I were implementing exfat and
> Christoph was saying "throw it away and extend fs/fat"
> then that's what I'd be doing.

Again, I'm not ruling that out if that's the consensus direction. After all,
the goal is to merge a working driver - and for that, I need to produce
something that the file system maintainers will be willing to merge, which
means doing it in a way they want it...

Hopefully next week a few other people will weigh in with what they prefer as
far as approach goes.  Only definite statement I've heard so far was
Christoph's...

> and we don't want more. Implementing exfat on top of fs/fat kills
> two birds with one stone - it modernises the fs/fat code base and
> brings new functionality that will have more developers interested
> in maintaining it over the long term.

Any recommendations on how to approach that?   Clone the current fs/fat code
and develop on top of that, or create a branch of it and on occasion do the
merging needed to track further fs/fat development?

Mostly asking for workflow suggestions - what's known to work well for this
sort of situation, where we know we won't be merging until we have several
thousand lines of new code?  And any "don't do <this> or you'll regret it
later" advice is also appreciated. :)


--==_Exmh_1567379634_4251P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Comment: Exmh version 2.9.0 11/07/2018

iQIVAwUBXWxQsgdmEQWDXROgAQIEChAAkp7n5MxBSc3LAt80yIYEqpOUllyAzLk+
se7lfnDiTSO/4D9ByufM6MDCfpGMCXn09h1yO/iltQ2gZZ0DfQuQdTIL1579v9u6
/fFvMnxcRmILRQt8rJw1arjPJcWHUjO97HcFh1e3rA7d7Om3I3fU9nwd/OVrZfiS
/GiSLHrBtRGvir/YJsiTIb6Sguv7TB+sKKekUVOCmT2h/zsLC1ElOnW0MiL8R8bq
ROT4IkyBZQFanoRLC9aQbDqGVl+wn7QRGXHXpsvixEG4pyj9oxHFpMBvXOOC2fTU
fElyh8gjzIJ2H6ZW6anGgTpY+W0ZnzZDMXfVBP+6uEmrfPQ/oWB2GUzpaiXeB7hb
su6eaJcACwm5Tza8mwwIoCNjhP6Bg+dDOuCneeAKon9/FTl2d2/u5cUNoj5+rWSI
9xZf1Anxv5BsOwunzkWIH5lcni8X/Wbm2bBWU4BDOQYooFiLaLlwfWxHtj9UGBGC
AN3HzUW/p4Uc4NsSwFQ67VgZWTMEvmfG4x6IRIZOY27lDlJoZBV86Cw7VXdQ0HLq
1w5k91HR9gslP4/qYsecH45VpvbjIakTC+eehE5iTtkJyZBkvEK7E6OOBdQemVM9
QMg7V7IQJV9+3VLnaItG07kxZPijXGNeB4i76Sj4cz5otcGhMSjFPxNzfQ1ycTwF
E9Vtf9AVaoE=
=JCXU
-----END PGP SIGNATURE-----

--==_Exmh_1567379634_4251P--