LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Park Ju Hyung <qkrwngud825@gmail.com>
To: valdis.kletnieks@vt.edu, gregkh@linuxfoundation.org,
	namjae.jeon@samsung.com
Cc: alexander.levin@microsoft.com, devel@driverdev.osuosl.org,
	linkinjeon@gmail.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, sergey.senozhatsky@gmail.com
Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to
Date: Tue, 17 Sep 2019 14:31:34 +0900
Message-ID: <20190917053134.27926-1-qkrwngud825@gmail.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.

  reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20190917025738epcas1p1f1dd21ca50df2392b0f84f0340d82bcd@epcas1p1.samsung.com>
     [not found] ` <003601d56d03$aa04fa00$fe0eee00$@samsung.com>
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 \
    --in-reply-to=20190917053134.27926-1-qkrwngud825@gmail.com \
    --to=qkrwngud825@gmail.com \
    --cc=alexander.levin@microsoft.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linkinjeon@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namjae.jeon@samsung.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=valdis.kletnieks@vt.edu \
    /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 \
		linux-kernel@vger.kernel.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