RE: [PATCH] staging: exfat: add exfat filesystem code to
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! 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. Thanks! > -- Forwarded message - > 보낸사람: Ju Hyung Park > Date: 2019년 9월 16일 (월) 오전 3:49 > Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to > To: Greg KH > Cc: , , fsde...@vger.kernel.org>, , Valdis Kletnieks > > > > Hi Greg, > > On Sun, Sep 15, 2019 at 10:54 PM Greg KH 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 ne
RE: [PATCH] staging: exfat: add exfat filesystem code to
I've summarized some of the big differences between sdfat and exfat in linux-next. 1. sdfat has been refactored to improve compatibility, readability and to be linux friendly.(included support mass storages larger than 2TB.) 2. sdfat has been optimized for the performance of SD-cards. - Support SD-card friendly block allocation and delayed allocation for vfat-fs only. - Support aligned_mpage_write for both vfat-fs and exfat-fs 3. sdfat has been optimized for the performance of general operations like create,lookup and readdir. 4. Fix many critical and minor bugs - Handle many kinds of error conditions gracefully to prevent panic. - Fix critical bugs related to rmdir, truncate behavior and so on... 5. Fix NLS functions Note, that Samsung is still improving sdfat driver. For instance, what will be realeased soon is sdfat v2.3.0, which will include support for "UtcOffset" of "File Directory Entry", in order to satisfy exFAT specification 7.4. Thanks! > -Original Message- > From: Ju Hyung Park [mailto:qkrwngud...@gmail.com] > Sent: Tuesday, September 17, 2019 3:04 PM > To: Greg KH; namjae.j...@samsung.com; Valdis Kletnieks > Cc: de...@driverdev.osuosl.org; linkinj...@gmail.com; linux- > ker...@vger.kernel.org; alexander.le...@microsoft.com; > sergey.senozhat...@gmail.com; linux-fsde...@vger.kernel.org > Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to > > On Tue, Sep 17, 2019 at 2:47 PM Greg KH wrote: > > It's the fact that it actually was in a form that could be merged, no > > one has done that with the sdfat code :) > > Well, I'm more than happy to help if you guys are happy with merging > the new base. > > > What fixes? That's what I'm asking here. > > I gave this as an example in my previous email: > https://github.com/MotorolaMobilityLLC/kernel-msm/commit/7ab1657 > > > 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'." :( > > The new sdFAT base I'm suggesting, is just as "random" as the one > staging tree is based on. > > If exFAT gets merged to Torvald's tree, there will be a lot more eyes > interested in it. > If there's a better base, we better switch to it now and prevent > further headaches long-term. > > It's really hard to compare those 2 drivers base and extract > meaningful changelogs. > > But regardless, here are some diff stats: > > Kconfig | 79 +- > Makefile | 46 +- > api.c| 423 > api.h| 310 --- > blkdev.c | 409 +--- > cache.c | 1142 - > config.h | 49 - > core.c | 5583 > core.h | 196 -- > core_exfat.c | 1553 > exfat.h | 1309 +++ > exfat_fs.h | 417 > extent.c | 351 --- > fatent.c | 182 -- > misc.c | 401 > nls.c| 490 ++-- > super.c | 5103 +--- > upcase.c | 740 ++ > upcase.h | 407 > version.h| 29 - > xattr.c | 136 -- > 21 files changed, 8186 insertions(+), 11169 deletions(-) > > > Kconfig | 79 +- > Makefile | 46 +- > blkdev.c | 409 +--- > cache.c | 1142 +- > core.c | 5583 ++-- > exfat.h | 1309 > nls.c| 490 ++--- > super.c | 5103 ++- > 8 files changed, 7446 insertions(+), 6715 deletions(-) > > > 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. > > Would there be any more data that I can provide? > It's really hard to go through the full diff :( > > Thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] staging: exfat: add exfat filesystem code to
[..] > Put it in drivers/staging/sdfat/. > > But really we want someone from Samsung to say that they will treat > the staging version as upstream. It doesn't work when people apply > fixes to their version and a year later back port the fixes into > staging. The staging tree is going to have tons and tons of white space > fixes so backports are a pain. All development needs to be upstream > first where the staging driver is upstream. Otherwise we should just > wait for Samsung to get it read to be merged in fs/ and not through the > staging tree. Quite frankly, This whole thing came as a huge-huge surprise to us, we did not initiate upstreaming of exfat/sdfat code and, as of this moment, I'm not exactly sure that we are prepared for any immediate radical changes to our internal development process which people all of a sudden want from us. I need to discuss with related people on internal thread. please wait a while:) Thanks! > > regards, > dan carpenter > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] staging: exfat: add exfat filesystem code to
> [..] > > Put it in drivers/staging/sdfat/. > > > > But really we want someone from Samsung to say that they will treat > > the staging version as upstream. It doesn't work when people apply > > fixes to their version and a year later back port the fixes into > > staging. The staging tree is going to have tons and tons of white space > > fixes so backports are a pain. All development needs to be upstream > > first where the staging driver is upstream. Otherwise we should just > > wait for Samsung to get it read to be merged in fs/ and not through the > > staging tree. > Quite frankly, > This whole thing came as a huge-huge surprise to us, we did not initiate > upstreaming of exfat/sdfat code and, as of this moment, I'm not exactly > sure that we are prepared for any immediate radical changes to our internal > development process which people all of a sudden want from us. I need to > discuss with related people on internal thread. > please wait a while:) We decide to contribute sdfat directly and treat upstream exfat. Perhaps more time is needed for patch preparation(exfat rename + vfat removal + clean-up) and internal processes. After contributing sdfat v2.2.0 as the base, We will also provide change-set of sdfat v2.3.0 later. Thanks! > > Thanks! > > > > regards, > > dan carpenter > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: exfat: add STAGING prefix to config names
Add STAGING prefix to config names to avoid collsion with fs/exfat config.
Signed-off-by: Namjae Jeon
---
drivers/staging/Makefile | 2 +-
drivers/staging/exfat/Kconfig| 26 +++
drivers/staging/exfat/Makefile | 2 +-
drivers/staging/exfat/exfat.h| 14
drivers/staging/exfat/exfat_blkdev.c | 12 +++
drivers/staging/exfat/exfat_core.c | 8 ++---
drivers/staging/exfat/exfat_super.c | 50 ++--
7 files changed, 57 insertions(+), 57 deletions(-)
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 463aef6a18ef..fdd03fd6e704 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -48,7 +48,7 @@ obj-$(CONFIG_FIELDBUS_DEV) += fieldbus/
obj-$(CONFIG_KPC2000) += kpc2000/
obj-$(CONFIG_UWB) += uwb/
obj-$(CONFIG_USB_WUSB) += wusbcore/
-obj-$(CONFIG_EXFAT_FS) += exfat/
+obj-$(CONFIG_STAGING_EXFAT_FS) += exfat/
obj-$(CONFIG_QLGE) += qlge/
obj-$(CONFIG_NET_VENDOR_HP)+= hp/
obj-$(CONFIG_WFX) += wfx/
diff --git a/drivers/staging/exfat/Kconfig b/drivers/staging/exfat/Kconfig
index 0130019cbec2..292a19dfcaf5 100644
--- a/drivers/staging/exfat/Kconfig
+++ b/drivers/staging/exfat/Kconfig
@@ -1,41 +1,41 @@
# SPDX-License-Identifier: GPL-2.0
-config EXFAT_FS
+config STAGING_EXFAT_FS
tristate "exFAT fs support"
depends on BLOCK
select NLS
help
This adds support for the exFAT file system.
-config EXFAT_DISCARD
+config STAGING_EXFAT_DISCARD
bool "enable discard support"
- depends on EXFAT_FS
+ depends on STAGING_EXFAT_FS
default y
-config EXFAT_DELAYED_SYNC
+config STAGING_EXFAT_DELAYED_SYNC
bool "enable delayed sync"
- depends on EXFAT_FS
+ depends on STAGING_EXFAT_FS
default n
-config EXFAT_KERNEL_DEBUG
+config STAGING_EXFAT_KERNEL_DEBUG
bool "enable kernel debug features via ioctl"
- depends on EXFAT_FS
+ depends on STAGING_EXFAT_FS
default n
-config EXFAT_DEBUG_MSG
+config STAGING_EXFAT_DEBUG_MSG
bool "print debug messages"
- depends on EXFAT_FS
+ depends on STAGING_EXFAT_FS
default n
-config EXFAT_DEFAULT_CODEPAGE
+config STAGING_EXFAT_DEFAULT_CODEPAGE
int "Default codepage for exFAT"
default 437
- depends on EXFAT_FS
+ depends on STAGING_EXFAT_FS
help
This option should be set to the codepage of your exFAT filesystems.
-config EXFAT_DEFAULT_IOCHARSET
+config STAGING_EXFAT_DEFAULT_IOCHARSET
string "Default iocharset for exFAT"
default "utf8"
- depends on EXFAT_FS
+ depends on STAGING_EXFAT_FS
help
Set this to the default input/output character set you'd like exFAT
to use.
diff --git a/drivers/staging/exfat/Makefile b/drivers/staging/exfat/Makefile
index 6c90aec83feb..057556eeca0c 100644
--- a/drivers/staging/exfat/Makefile
+++ b/drivers/staging/exfat/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-or-later
-obj-$(CONFIG_EXFAT_FS) += exfat.o
+obj-$(CONFIG_STAGING_EXFAT_FS) += exfat.o
exfat-y := exfat_core.o\
exfat_super.o \
diff --git a/drivers/staging/exfat/exfat.h b/drivers/staging/exfat/exfat.h
index 51c665a924b7..3865c17027ce 100644
--- a/drivers/staging/exfat/exfat.h
+++ b/drivers/staging/exfat/exfat.h
@@ -9,7 +9,7 @@
#include
#include
-#ifdef CONFIG_EXFAT_KERNEL_DEBUG
+#ifdef CONFIG_STAGING_EXFAT_KERNEL_DEBUG
/* For Debugging Purpose */
/* IOCTL code 'f' used by
* - file systems typically #0~0x1F
@@ -22,9 +22,9 @@
#define EXFAT_DEBUGFLAGS_INVALID_UMOUNT0x01
#define EXFAT_DEBUGFLAGS_ERROR_RW 0x02
-#endif /* CONFIG_EXFAT_KERNEL_DEBUG */
+#endif /* CONFIG_STAGING_EXFAT_KERNEL_DEBUG */
-#ifdef CONFIG_EXFAT_DEBUG_MSG
+#ifdef CONFIG_STAGING_EXFAT_DEBUG_MSG
#define DEBUG 1
#else
#undef DEBUG
@@ -661,10 +661,10 @@ struct exfat_mount_options {
/* on error: continue, panic, remount-ro */
unsigned char errors;
-#ifdef CONFIG_EXFAT_DISCARD
+#ifdef CONFIG_STAGING_EXFAT_DISCARD
/* flag on if -o dicard specified and device support discard() */
unsigned char discard;
-#endif /* CONFIG_EXFAT_DISCARD */
+#endif /* CONFIG_STAGING_EXFAT_DISCARD */
};
#define EXFAT_HASH_BITS8
@@ -700,9 +700,9 @@ struct exfat_sb_info {
spinlock_t inode_hash_lock;
struct hlist_head inode_hashtable[EXFAT_HASH_SIZE];
-#ifdef CONFIG_EXFAT_KERNEL_DEBUG
+#ifdef CONFIG_STAGING_EXFAT_KERNEL_DEBUG
long debug_flags;
-#endif /* CONFIG_EXFAT_KERNEL_DEBUG */
+#endif /* CONFIG_STAGING_EXFAT_KERNEL_DEBUG */
};
/*
diff --git a/drivers/staging/exfat/exfat_blkdev.c
b/drivers/staging/exfat/exfat_blkdev.c
index 7bcd98b13109..8791a5f2bb08 100644
--- a/d
[PATCH] staging: exfat: make staging/exfat and fs/exfat mutually exclusive
From: Namjae Jeon Make staging/exfat and fs/exfat mutually exclusive to select the one between two same filesystem. Suggested-by: Amir Goldstein Signed-off-by: Namjae Jeon --- drivers/staging/exfat/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/exfat/Kconfig b/drivers/staging/exfat/Kconfig index 292a19dfcaf5..9a0fccec65d9 100644 --- a/drivers/staging/exfat/Kconfig +++ b/drivers/staging/exfat/Kconfig @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 config STAGING_EXFAT_FS tristate "exFAT fs support" - depends on BLOCK + depends on BLOCK && !EXFAT_FS select NLS help This adds support for the exFAT file system. -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: exfat: make staging/exfat and fs/exfat mutually exclusive
2020-01-12 2:56 GMT+09:00, Greg KH : > On Sat, Jan 11, 2020 at 09:14:19PM +0900, Namjae Jeon wrote: >> From: Namjae Jeon >> >> Make staging/exfat and fs/exfat mutually exclusive to select the one >> between two same filesystem. >> >> Suggested-by: Amir Goldstein >> Signed-off-by: Namjae Jeon >> --- >> drivers/staging/exfat/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/staging/exfat/Kconfig >> b/drivers/staging/exfat/Kconfig >> index 292a19dfcaf5..9a0fccec65d9 100644 >> --- a/drivers/staging/exfat/Kconfig >> +++ b/drivers/staging/exfat/Kconfig >> @@ -1,7 +1,7 @@ >> # SPDX-License-Identifier: GPL-2.0 >> config STAGING_EXFAT_FS >> tristate "exFAT fs support" >> -depends on BLOCK >> +depends on BLOCK && !EXFAT_FS > > There is no such symbol in the kernel tree, so this isn't going to do > anything :( > > When/if EXFAT_FS does show up, I will be glad to add this. Or better > yet, just have this as part of the "real" exfat patchset, that would > make the most sense, right? Right, Thanks! > > thanks, > > greg k-h > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
