From: Park Ju Hyung <email@example.com> To: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to Date: Tue, 17 Sep 2019 14:31:34 +0900 Message-ID: <email@example.com> (raw) In-Reply-To: <8998.1568693976@turing-police> On Tue, 17 Sep 2019 00:19:36 -0400, "Valdis Klētnieks" said: > I'm working off a somewhat cleaned up copy of Samsung's original driver, > because that's what I had knowledge of. If the sdfat driver is closer to being > mergeable, I'd not object if that got merged instead. Greg, as Valdis mentioned here, the staging tree driver is just another exFAT fork from Samsung. What's the point of using a much older driver? sdFAT is clearly more matured and been put into more recent production softwares. And as I wrote in previous email, it does include some real fixes. As Namjae said too, Samsung would be more interested in merging sdFAT to upstream. If we diverge, Samsung will have less reasons to contribute their patches to upstream. Also, I think it makes much more sense to make Samsung the maintainer of this driver (if they're willing to put in the manpower to do so). Asking them would be the first step in doing so. > But here's the problem... Samsung has their internal sdfat code, Park Yu Hyung > has what appears to be a fork of that code from some point (and it's unclear , > and it's unclear which one has had more bugfixes and cleanups to get it to > somewhere near mainline mergeable. I made it extremely clear on where I took the code. The initial commit: "sdfat: import from G973FXXU3ASG8" states which kernel source I used. You can simply search "G973FXXU3ASG8" on http://opensource.samsung.com and download the source code. It'll match exactly with my initial commit. My repository is basically rename + clean-up + older kernel compat. I think we can all agree that using the sdFAT naming on non-Android is very misleading, which is why I renamed it to exFAT. sdFAT includes support for fat16/32, and as also mentioned in https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-next&id=58985a9d2d03e977db93bf574a16162766a318fe this isn't desirable, especially in mainline. I cleaned it up and removed some other Samsung's code that relies on proprietary userspace tools such as defrag. I believe my repository is in the cleanest state for getting merged to mainline, compared to other drivers avilable out there. If we happen to pick it to mainline, I think it'll also be quite trivial for Samsung to pick mainline patches back to their sdFAT drivers used in Galaxy devices. > Can you provide a pointer to what Samsung is *currently* using? We probably > need to stop and actually look at the code bases and see what's in the best > shape currently. Namjae could probably elaborate here, but if I were to guess, there wasn't a noticeable difference in recent sdFAT releases. Even the lastest Note10 kernel only had some uevent changes. I think the current latest public source's driver is the best one available. Thanks.
next prev parent reply index Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CGME20190917025738epcas1p1f1dd21ca50df2392b0f84f0340d82bcd@epcas1p1.samsung.com> [not found] ` <firstname.lastname@example.org> 2019-09-17 3:02 ` Namjae Jeon 2019-09-17 4:19 ` Valdis Klētnieks 2019-09-17 5:31 ` Park Ju Hyung [this message] 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 2019-08-28 16:08 [PATCH] staging: exfat: add exfat filesystem code to staging Greg Kroah-Hartman 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
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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