The Initial exFAT Driver Queued For Introduction With The Linux 5.4 Kernel

[phoronix]

Phoronix: The Initial exFAT Driver Queued For Introduction With The Linux 5.4 Kernel

The Linux 5.4 kernel merge window will kick off in September and with this next kernel cycle the initial open-source exFAT file-system driver is set to be mainlined for supporting this Microsoft file-system, but it will premiere within the kernel's "staging" area for code of lesser, yet-to-be-proven quality...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.4-exFAT-Is-Coming

[tildearrow]

it at least functions for dealing with exFAT file-systems and better than having no support at all.

If it corrupts my drives (possible due to the poor code quality), I consider it to provide "no support at all".

[jrch2k8]

Linus will go nuclear in 3 2 ....(i hope so at least )

[starshipeleven]

If it corrupts my drives (possible due to the poor code quality), I consider it to provide "no support at all".

You can consider what you want, but even just being able to read the drives is "better than no support at all"

That said, why not using the FUSE driver. The device (USB drive or card)'s own performance is going to be the bigger bottleneck anyway.

[tildearrow]

Linus will go nuclear in 3 2 ....(i hope so at least )

...Zero!

The exfat code seems like absolute pure CoC that has never seen a compiler. I'm upset, because I expect better quality control. In fact, I expect *some* qualitty control, and this piece-of-CoC driver has clearly seen none at all. And those patches were apparently committed yesterday. WHAT THE ACTUAL CoC?...How the CoC did this get to the point where CoC like this is even sent to me? Nobody tested *anything*? AND WHY THE CoC WAS THIS UTTER CoC SENT TO ME IF IT WAS COMMITTED YESTERDAY?

[starshipeleven]

I would really like to have TexFAT (aka Transaction Safe extFAT), which basically removed a common and useful FAT32 feature that is now locked and supposed to be used by "windows CE embedded" only.
And of course this isn't in the spec release either.
https://en.wikipedia.org/wiki/ExFAT
The standard exFAT implementation is not journaled and only uses a single file allocation table and free space map. FAT file systems instead used alternating tables, as this allowed recovery of the file system if the media was ejected during a write (which occurs frequently in practice with removable media). The optional TexFAT component adds support for additional backup tables and maps, but may not be supported.

[starshipeleven]

...Zero!

That's for tinydrm driver, which was
1. submitted for mainline
2. actually not compiling for shit
3. throwing some funny warnings

https://lkml.org/lkml/2017/2/23/611

This driver compiles fine and is not for mainline.

So put away your popcorn.

[tildearrow]

That's for tinydrm driver, which was
1. submitted for mainline
2. actually not compiling for shit
3. throwing some funny warnings

https://lkml.org/lkml/2017/2/23/611

This driver compiles fine and is not for mainline.

So put away your popcorn.

It was a joke. I didn't mean to bring any popcorn to the table!

[starshipeleven]

It was a joke. I didn't mean to bring any popcorn to the table!

Too bad, I was hungry

[tildearrow]

Too bad, I was hungry

I'll do my best to prevent the thread from heating up.

Anyways, back to topic. Yes, I agree having at least just read support is "some support", but I'm sure most people want read/write support.