Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat

["Valdis Klētnieks" <valdis.kletnieks@vt.edu>]

[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]

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. :)


[-- Attachment #2: Type: application/pgp-signature, Size: 832 bytes --]