We are excited to see this happening and would like to state that we appreciate time and effort which people put into upstreaming exfat. Thank you! However, if possible, can we step back a little bit and re-consider it? We would prefer to see upstream the code which we are currently using in our products - sdfat - as this can be mutually benefitial from various points of view. Thanks! > ---------- Forwarded message --------- > 보낸사람: Ju Hyung Park <qkrwngud825@xxxxxxxxx> > Date: 2019년 9월 16일 (월) 오전 3:49 > Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to > To: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> > Cc: <alexander.levin@xxxxxxxxxxxxx>, <devel@xxxxxxxxxxxxxxxxxxxx>, <linux- > fsdevel@xxxxxxxxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, Valdis Kletnieks > <valdis.kletnieks@xxxxxx> > > > Hi Greg, > > On Sun, Sep 15, 2019 at 10:54 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > Note, this just showed up publically on August 12, where were you with > > all of this new code before then? :) > > My sdFAT port, exfat-nofuse and the one on the staging tree, were all > made by Samsung. > And unless you guys had a chance to talk to Samsung developers > directly, those all share the same faith of lacking proper development > history. > > The source I used was from http://opensource.samsung.com, which > provides kernel sources as tar.gz files. > There is no code history available. > > > For the in-kernel code, we would have to rip out all of the work you did > > for all older kernels, so that's a non-starter right there. > > I'm aware. > I'm just letting mainline know that there is potentially another (much > better) base that could be upstreamed. > > If you want me to rip out older kernel support for upstreaming, I'm > more than happy to do so. > > > As for what codebase to work off of, I don't want to say it is too late, > > but really, this shows up from nowhere and we had to pick something so > > we found the best we could at that point in time. > > To be honest, whole public exFAT sources are all from nowhere unless > you had internal access to Samsung's development archive. > The one in the current staging tree isn't any better. > > I'm not even sure where the staging driver is from, actually. > > Samsung used the 1.2.x versioning until they switched to a new code > base - sdFAT. > The one in the staging tree is marked version 1.3.0(exfat_super.c). > I failed to find anything 1.3.x from Samsung's public kernel sources. > > The last time exFAT 1.2.x was used was in Galaxy S7(released in 2016). > Mine was originally based on sdFAT 2.1.10, used in Galaxy S10(released > in March 2019) and it just got updated to 2.2.0, used in Galaxy > Note10(released in August 2019). > > > Is there anything specific in the codebase you have now, that is lacking > > in the in-kernel code? Old-kernel-support doesn't count here, as we > > don't care about that as it is not applicable. But functionality does > > matter, what has been added here that we can make use of? > > This is more of a suggestion of > "Let's base on a *much more recent* snapshot for the community to work on", > since the current one on the staging tree also lacks development history. > > The diff is way too big to even start understanding the difference. > > > With that said though, I do have some vague but real reason as to why > sdFAT base is better. > > With some major Android vendors showing interests in supporting exFAT, > Motorola notably published their work on public Git repository with > full development history(the only vendor to do this that I'm aware > of). > Commits like this: > https://github.com/MotorolaMobilityLLC/kernel-msm/commit/7ab1657 is > not merged to exFAT(including the current staging tree one) while it > did for sdFAT. > > > The only thing I regret is not working on porting sdFAT sooner. > I definitely didn't anticipate Microsoft to suddenly lift legal issues > on upstreaming exFAT just around when I happen to gain interest in > porting sdFAT. > > If my port happened sooner, it would have been a no-brainer for it to > be considered as a top candidate for upstreaming. > > > And do you have any "real" development history to look at instead of the > > "one giant commit" of the initial code drop? That is where we could > > actually learn what has changed over time. Your repo as-is shows none > > of the interesting bits :( > > As I mentioned, development history is unobtainable, even for the > current staging tree or exfat-nofuse. > (If you guys took exfat-nofuse, you can also see that there's barely > any real exFAT-related development done in that tree. Everything is > basically fixes for newer kernel versions.) > > The best I could do, if someone's interested, is to diff all versions > of exFAT/sdFAT throughout the Samsung's kernel versions, but that > still won't give us reasons as to why the changes were made. > > TL;DR > My suggestion - Let's base on a much newer driver that's matured more, > contains more fixes, gives (slightly?) better performance and > hopefully has better code quality. > > Both drivers are horrible. > You said it yourself(for the current staging one), and even for my new > sdFAT-base proposal, I'm definitely not comfortable seeing this kind > of crap in mainline: > https://github.com/arter97/exfat-linux/commit/0f1ddde > > However, it's clear to me that the sdFAT base is less-horrible. > > Please let me know what you think. > > > thanks, > > > > greg kh > > Thanks. >
