[PATCH] staging: exfat: add exfat filesystem code to

Valdis Kl=?utf-8?Q?=c4=93?=tnieks valdis.kletnieks at vt.edu
Tue Sep 17 04:19:36 UTC 2019

On Tue, 17 Sep 2019 12:02:01 +0900, "Namjae Jeon" said:
> We are excited to see this happening and would like to state that we appreciate time and
> effort which people put into upstreaming exfat. Thank you!

The hard part - getting Microsoft to OK merging an exfat driver - is done.

All we need now is to get a driver cleaned up. :)

> However, if possible, can we step back a little bit and re-consider it? We would prefer to
> see upstream the code which we are currently using in our products - sdfat - as
> this can be mutually benefitial from various points of view.

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.

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.

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/attachments/20190917/e2f2afd7/attachment.asc>

More information about the devel mailing list