Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > On Mon, Sep 02, 2019 at 03:00:17PM -0400, Valdis Klētnieks wrote: >> On Mon, 02 Sep 2019 17:25:24 +0200, Greg Kroah-Hartman said: >> >> > I dug up my old discussion with the current vfat maintainer and he said >> > something to the affect of, "leave the existing code alone, make a new >> > filesystem, I don't want anything to do with exfat". >> > >> > And I don't blame them, vfat is fine as-is and stable and shouldn't be >> > touched for new things. >> > >> > We can keep non-vfat filesystems from being mounted with the exfat >> > codebase, and make things simpler for everyone involved. >> >> Ogawa: >> >> Is this still your position, that you want exfat to be a separate module? > > Personally I agree that this should be separate at least for quite some > time to shake things out at the very least. But I'll defer to Ogawa if > he thinks things should be merged. I'm not reading whole of this thread, so I can be pointless though. I can't recall the discussion of exfat with you. My history about exfat is, write read-only exfat from on-disk data -> MS published patent to their site or such -> stopped about exfat -> recently looks like MS changed mind Well, if you are going to developing actively, IMO it would be better to drop historically bad decisions in fat driver (some stuff would be hard to fix without user visible changes), and re-think from basic implementation design. And I can't recall the detail of exfat format though, IIRC, the common code is not so big, but some stuff can be shared with fat (timestamp stuff, fatent stuff, IIRC). So IMO it is better to be different driver basically, however on other hand, it is better to share the code for same on-disk format if possible. Anyway, I don't have strong opinion about it. Thanks. -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
