Hello, thank you for input! On Thursday 29 August 2019 19:35:06 Sasha Levin wrote: > On Thu, Aug 29, 2019 at 07:18:16PM -0400, Valdis Klētnieks wrote: > > On Thu, 29 Aug 2019 22:56:31 +0200, Pali Roh?r said: > > > > > I'm not really sure if this exfat implementation is fully suitable for > > > mainline linux kernel. > > > > > > In my opinion, proper way should be to implement exFAT support into > > > existing fs/fat/ code instead of replacing whole vfat/msdosfs by this > > > new (now staging) fat implementation. > > > > > In linux kernel we really do not need two different implementation of > > > VFAT32. > > > > This patch however does have one major advantage over "patch vfat to > > support exfat" - which is that the patch exists. > > > > If somebody comes forward with an actual "extend vfat to do exfat" patch, > > we should at that point have a discussion about relative merits.... > > This patch going into staging doesn't necessarily mean that one day > it'll get moved to fs/exfat/. It's very possible that the approach would > instead be to use the staging code for reference, build this > functionality in fs/fat/, and kill off the staging code when it's not > needed anymore. So, if current exfat code is just going to be "reference" how to implement exfat properly in fs/fat, is this correct usage of "staging"? I was in impression that staging is there for drivers which needs cleanup as they are not ready to be part of mainline. But not that it is for "random" implementation of something which is going to be just a "code example" or "reference" for final implementation which would be different. Maybe other people could clarify state of staging, if this is how staging should be used or not. > With regards to missing specs/docs/whatever - our main concern with this > release was that we want full interoperability, which is why the spec > was made public as-is without modifications from what was used > internally. There's no "secret sauce" that Microsoft is hiding here. Ok, if it was just drop of "current version" of documentation then it makes sense. > How about we give this spec/code time to get soaked and reviewed for a > bit, and if folks still feel (in a month or so?) that there are missing > bits of information related to exfat, I'll be happy to go back and try > to get them out as well. Basically external references in that released exFAT specification are unknown / not released yet. Like TexFAT. So if you have an input in MS could you forward request about these missing bits? Also, MS already released source code of FAT32 kernel driver (fastfat.sys) and from code can be seen that it does not match MS FAT specification, and include some "secret sauce" bits. Source code is on: https://github.com/microsoft/Windows-driver-samples/tree/master/filesys/fastfat In fastfat.sys there is e.g. usage of undocumented bits in directory entry or usage of undocumented bits for marking filesystem as "dirty" -- incorrectly unmounted. Would it be possible for MS to release in same way code of exFAT NT driver? I'm really a bit sceptical that exFAT MS implementation is really according to standard as I already known that FAT32 is not. Just to note that I did some investigation in FAT32 level how are handled volume labels and I found more bugs in current implementations (mtools, dosfstools, util-linux and even in fastfat.sys). Some references are on: https://www.spinics.net/lists/kernel/msg2640891.html Fixes for mtools, dosfstools and util-linux were already applied and fix for MS's fastfat.sys is pending in opened pull request: https://github.com/microsoft/Windows-driver-samples/pull/303 Could you please forward my pull request for fastfat.sys fixes to appropriate people/team in MS? -- Pali Rohár pali.rohar@xxxxxxxxx
