On Thu, Aug 29, 2019 at 03:37:49AM -0700, Christoph Hellwig wrote: > On Thu, Aug 29, 2019 at 11:50:19AM +0200, Greg Kroah-Hartman wrote: > > I did try just that, a few years ago, and gave up on it. I don't think > > it can be added to the existing vfat code base but I am willing to be > > proven wrong. > > And what exactly was the problem? At the time, I just couldn't figure out how to do it as I had no spec, and only a bad code-base to go off of. I'm sure someone else might be able to do to it :) > > Now that we have the specs, it might be easier, and the vfat spec is a > > subset of the exfat spec, but to get stuff working today, for users, > > it's good to have it in staging. We can do the normal, "keep it in > > stable, get a clean-room implementation merged like usual, and then > > delete the staging version" three step process like we have done a > > number of times already as well. > > > > I know the code is horrible, but I will gladly take horrible code into > > staging. If it bothers you, just please ignore it. That's what staging > > is there for :) > > And then after a while you decide it's been long enough and force move > it out of staging like the POS erofs code? Hey, that's not nice, erofs isn't a POS. It could always use more review, which the developers asked for numerous times. There's nothing different from a filesystem compared to a driver. If its stand-alone, and touches nothing else, all issues with it are self-contained and do not bother anyone else in the kernel. We merge drivers all the time that need more work because our review cycles are low. And review cycles for vfs developers are even more scarce than driver reviewers. thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
