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:
pgpXx04BoDDQO.pgp
Description: PGP signature
