Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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>
In-Reply-To: <8998.1568693976@turing-police>
References: <8998.1568693976@turing-police>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.