LKML Archive on
 help / color / Atom feed
From: Greg KH <>
To: Park Ju Hyung <>
Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to
Date: Tue, 17 Sep 2019 07:47:26 +0200
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Sep 17, 2019 at 02:31:34PM +0900, Park Ju Hyung wrote:
> 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?

It's the fact that it actually was in a form that could be merged, no
one has done that with the sdfat code :)

> 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.

What fixes?  That's what I'm asking here.

How do we "know" that this is better than what we currently have today?
We don't, so it's a bit hard to tell someone, "delete the work you did
and replace it with this other random chunk of code, causing you a bunch
more work in the process for no specific reason other than it looks
'newer'." :(

> 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.

Are they going to do this if we do take the sdfat code?  If so, great,
but I need to get someone to agree that this will happen.

> 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.

They are more than willing to start contributing and being a
co-maintainer of it, it needs all the help it can get.

But "someone" from samsung, or anywhere else, has to be willing to step
up here and do this work.  Without that happening, I don't see a reason
to change at this point in time.

Rembember, kernel development happens because people do the work, which
Valdis did, and continues to do.  Throwing that away because of the
thought that someone else might do some work in the future is not how we

I recommend looking at what we have in the tree now, and seeing what is
missing compared to "sdfat".  I know a lot of places in the exfat code
that needs to be fixed up, odds are they are the same stuff that needs
to be resolved in sdfat as well.


greg k-h

  reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
     [not found] ` <003601d56d03$aa04fa00$fe0eee00$>
2019-09-17  3:02   ` 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 [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror 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/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone