From: Ju Hyung Park <email@example.com> To: Greg KH <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Valdis Kletnieks <email@example.com> Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to Date: Mon, 16 Sep 2019 01:11:14 +0900 Message-ID: <CAD14+f2EqjUfr+Xwx9CDoqvCdeFo0UqYrVxN=s8Yo4b3KTyZXA@mail.gmail.com> (raw) In-Reply-To: <20190915135409.GA553917@kroah.com> Hi Greg, On Sun, Sep 15, 2019 at 10:54 PM Greg KH <firstname.lastname@example.org> 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.
next prev parent reply index Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-28 16:08 [PATCH] staging: exfat: add exfat filesystem code to staging Greg Kroah-Hartman 2019-08-28 17:00 ` Greg Kroah-Hartman 2019-08-29 6:23 ` Christoph Hellwig 2019-08-29 6:39 ` Greg Kroah-Hartman 2019-08-29 9:41 ` Christoph Hellwig 2019-08-29 9:50 ` Greg Kroah-Hartman 2019-08-29 10:37 ` Christoph Hellwig 2019-08-29 11:04 ` Gao Xiang 2019-08-29 11:18 ` Greg Kroah-Hartman 2019-08-29 11:18 ` Greg Kroah-Hartman 2019-08-29 15:11 ` Dan Carpenter 2019-08-29 15:27 ` Gao Xiang 2019-08-29 15:43 ` Dan Carpenter 2019-08-29 15:51 ` Gao Xiang 2019-08-29 16:04 ` Gao Xiang 2019-08-30 8:34 ` Dan Carpenter 2019-08-30 8:43 ` Gao Xiang 2019-08-30 11:26 ` Dan Carpenter 2019-08-30 12:04 ` Gao Xiang 2019-08-29 16:44 ` Gao Xiang 2019-08-29 16:59 ` Joe Perches 2019-08-29 17:02 ` Gao Xiang 2019-08-30 2:06 ` Chao Yu 2019-08-30 6:38 ` Gao Xiang 2019-08-30 12:00 ` Checking usage of likeliness annotations Markus Elfring 2019-08-30 11:51 ` [PATCH] staging: exfat: add exfat filesystem code to staging David Sterba 2019-08-31 3:50 ` Chao Yu 2019-08-30 15:36 ` Christoph Hellwig 2019-08-30 21:54 ` Dave Chinner 2019-08-31 10:31 ` Valdis Klētnieks 2019-09-01 0:04 ` Dave Chinner 2019-08-29 7:01 ` Gao Xiang 2019-08-29 8:24 ` Gao Xiang 2019-08-29 9:51 ` Christoph Hellwig 2019-08-29 12:14 ` Pali Rohár 2019-08-29 12:34 ` Valdis Klētnieks 2019-08-29 12:46 ` Pali Rohár 2019-08-29 14:08 ` Markus Elfring 2019-08-29 15:44 ` Markus Elfring 2019-08-29 20:56 ` Pali Rohár 2019-08-29 23:18 ` Valdis Klētnieks 2019-08-29 23:35 ` Sasha Levin 2019-08-30 7:56 ` Pali Rohár 2019-10-16 14:03 ` Pali Rohár 2019-10-16 14:31 ` Sasha Levin 2019-10-16 16:03 ` Pali Rohár 2019-10-16 16:20 ` Sasha Levin 2019-10-16 16:22 ` Greg Kroah-Hartman 2019-10-16 16:32 ` Pali Rohár 2019-10-16 16:50 ` Greg Kroah-Hartman 2019-10-16 20:33 ` Sasha Levin 2019-10-16 21:53 ` Valdis Klētnieks 2019-10-17 7:53 ` Pali Rohár 2019-10-17 7:50 ` Pali Rohár 2019-10-16 16:05 ` Valdis Klētnieks 2019-08-30 8:03 ` Pali Rohár 2019-08-30 15:40 ` Christoph Hellwig 2019-08-30 15:43 ` Pali Rohár 2019-09-14 13:39 ` [PATCH] staging: exfat: add exfat filesystem code to Park Ju Hyung 2019-09-15 13:54 ` Greg KH 2019-09-15 16:11 ` Ju Hyung Park [this message] [not found] ` <email@example.com> 2019-09-18 20:12 ` [PATCH] staging: exfat: rebase to sdFAT v2.2.0 Greg KH 2019-09-18 20:13 ` Greg KH 2019-09-18 20:22 ` Ju Hyung Park 2019-09-18 20:26 ` Greg KH 2019-09-18 20:31 ` Ju Hyung Park 2019-09-18 20:46 ` Valdis Klētnieks 2019-09-18 21:31 ` kbuild test robot 2019-09-18 21:31 ` kbuild test robot 2019-09-18 22:17 ` Ju Hyung Park 2019-10-24 9:39 ` [PATCH] staging: exfat: add exfat filesystem code to staging Pali Rohár [not found] <CGME20190917025738epcas1p1f1dd21ca50df2392b0f84f0340d82bcd@epcas1p1.samsung.com> [not found] ` <firstname.lastname@example.org> 2019-09-17 3:02 ` [PATCH] staging: exfat: add exfat filesystem code to Namjae Jeon 2019-09-17 4:19 ` Valdis Klētnieks 2019-09-17 5:31 ` Park Ju Hyung 2019-09-17 5:47 ` Greg KH 2019-09-17 6:04 ` Ju Hyung Park 2019-09-18 2:35 ` Namjae Jeon 2019-09-18 6:16 ` Greg KH 2019-09-18 6:33 ` Sergey Senozhatsky 2019-09-18 8:26 ` Greg KH 2019-09-18 8:51 ` Sergey Senozhatsky 2019-09-18 9:01 ` Ju Hyung Park 2019-09-18 9:24 ` Dan Carpenter 2019-09-18 9:53 ` Ju Hyung Park 2019-09-18 10:08 ` Dan Carpenter 2019-09-18 10:46 ` Ju Hyung Park 2019-09-18 11:05 ` Greg KH 2019-09-19 2:14 ` Namjae Jeon 2019-09-30 4:25 ` Namjae Jeon 2019-09-30 6:08 ` Greg KH 2019-09-17 4:56 ` Greg KH 2019-09-17 5:15 ` Gao Xiang
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAD14+f2EqjUfr+Xwx9CDoqvCdeFo0UqYrVxN=s8Yo4b3KTyZXA@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ firstname.lastname@example.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git