LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Ju Hyung Park <qkrwngud825@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: alexander.levin@microsoft.com, devel@driverdev.osuosl.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Valdis Kletnieks <valdis.kletnieks@vt.edu>
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 <gregkh@linuxfoundation.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.

  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] ` <20190918195920.25210-1-qkrwngud825@gmail.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] ` <003601d56d03$aa04fa00$fe0eee00$@samsung.com>
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' \
    --to=qkrwngud825@gmail.com \
    --cc=alexander.levin@microsoft.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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