The Existing Linux exFAT Code Is "Horrible" But Could Soon Be In Staging

[phoronix]

Phoronix: The Existing Linux exFAT Code Is "Horrible" But Could Soon Be In Staging

Following Microsoft's approval of seeing exFAT support on Linux and at long last releasing public specifications to the file-system, the existing out-of-tree Linux driver code was quickly volleyed on the mailing list for review and hopeful inclusion into the kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-exFAT-Code-Staging

[L_A_G]

If the quality of the code is as bad as they say I do hope that either Linus puts his foot down or Greg comes to his senses and declares this driver a stopgap measure to be kicked out of the kernel once a much better driver written from scratch is ready to be mainlined. The fact that the code is apparently somewhat self-contained would in my opinion speak to this being the right approach.

Obviously a driver written with the proper specs in hand from the outset will be much better and way less "hacky" than one written with incomplete ones sussed out by reverse-engineering existing implementations.

[yoshi314]

staging is for badly coded drivers that people run at their own risk. it has always been used for that purpose.

if it stays unmaintained, it will get the boot.

[chuckula]

I've been using exFAT on Linux via the FUSE driver for a long time and never had a problem. Of course, I'm not running an enterprise DB on it or anything, I just use it to access SD cards, which is pretty much what exFAT was designed to do anyway.

Are there fundamental differences in the FUSE driver model vs. an in-kernel driver that would prevent a port to convert this driver from user-space to kernel-space?

[ALRBP]

I find strange that exFAT's "horrible" code would go to staging before being cleaned-up while AMD's DAL/DC bad code was completely rejected, even for staging, until cleaned-up.
There is no urgent need for exFAT support to be merged, since we have FUSE working perfectly for an FS essentially used for removable medias. exFAT will not be used for system partitions, so FUSE is perfectly fine. For AMD's DAL/DC, there was an urgent need for it, as AMD refused to make their latest cards work without and also, we needed it for HDMI audio and other features. In that case, the only other option was to use a proprietary driver that was not necessarily working on most recent kernels, so we really needed DAL/DC to be merged, unlike exFAT.

[chuckula]

I find strange that exFAT's "horrible" code would go to staging before being cleaned-up while AMD's DAL/DC bad code was completely rejected, even for staging, until cleaned-up.

I think it's probably because the DAL/DC code was not only horrible, but absolutely massive and invasive too. The exFAT module can be bad code, but it's self-contained to just one FS driver module and doesn't cause damage outside of its own sandbox. It's also probably tiny in size compared to the DAL/DC.

[carewolf]

I think it's probably because the DAL/DC code was not only horrible, but absolutely massive and invasive too. The exFAT module can be bad code, but it's self-contained to just one FS driver module and doesn't cause damage outside of its own sandbox. It's also probably tiny in size compared to the DAL/DC.

In fact one of exFAT's problems is supposedly being TOO self-contained.

[AsuMagic]

If the quality of the code is as bad as they say I do hope that either Linus puts his foot down or Greg comes to his senses and declares this driver a stopgap measure to be kicked out of the kernel once a much better driver written from scratch is ready to be mainlined. The fact that the code is apparently somewhat self-contained would in my opinion speak to this being the right approach.

Obviously a driver written with the proper specs in hand from the outset will be much better and way less "hacky" than one written with incomplete ones sussed out by reverse-engineering existing implementations.

Staging is meant to contain such code.
Nothing new.

[Serafean]

Staging is meant to contain such code.
Nothing new.

So was Experimental 10 years ago. Everybody enabled it, and staging was created.

[L_A_G]

Staging is meant to contain such code.
Nothing new.

Staging is meant for code that still needs work before it can be mainlined, not for code which is only a stopgap before being deleted entirely. He pulled it there because he thinks it just needs a bit of work and then it'll be fine. My opinion is that it needs considerably more than just a bit of work. It needs to be re-implemented from scratch following proper kernel code quality standards and based on the complete official specs Microsoft just put out.