* [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
@ 2019-08-30 16:42 Valdis Klētnieks
2019-08-30 16:45 ` Christoph Hellwig
0 siblings, 1 reply; 20+ messages in thread
From: Valdis Klētnieks @ 2019-08-30 16:42 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin, Christoph Hellwig
Cc: linux-fsdevel, linux-kernel
Concerns have been raised about the exfat driver accidentally mounting
fat/vfat file systems. Add an extra configure option to help prevent that.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
diff --git a/drivers/staging/exfat/Kconfig b/drivers/staging/exfat/Kconfig
index 78b32aa2ca19..1df177b1dc72 100644
--- a/drivers/staging/exfat/Kconfig
+++ b/drivers/staging/exfat/Kconfig
@@ -4,6 +4,14 @@ config EXFAT_FS
help
This adds support for the exFAT file system.
+config EXFAT_DONT_MOUNT_VFAT
+ bool "Prohibit mounting of fat/vfat filesysems by exFAT"
+ default y
+ help
+ By default, the exFAT driver will only mount exFAT filesystems, and refuse
+ to mount fat/vfat filesystems. Set this to 'n' to allow the exFAT driver
+ to mount these filesystems.
+
config EXFAT_DISCARD
bool "enable discard support"
depends on EXFAT_FS
diff --git a/drivers/staging/exfat/exfat_super.c b/drivers/staging/exfat/exfat_super.c
index 5b5c2ca8c9aa..7fdb5b8bc928 100644
--- a/drivers/staging/exfat/exfat_super.c
+++ b/drivers/staging/exfat/exfat_super.c
@@ -486,10 +486,16 @@ static int ffsMountVol(struct super_block *sb)
break;
if (i < 53) {
+#ifdef CONFIG_EXFAT_DONT_MOUNT_VFAT
+ ret = -EINVAL;
+ printk(KERN_INFO "EXFAT: Attempted to mount VFAT filesystem\n");
+ goto out;
+#else
if (GET16(p_pbr->bpb + 11)) /* num_fat_sectors */
ret = fat16_mount(sb, p_pbr);
else
ret = fat32_mount(sb, p_pbr);
+#endif
} else {
ret = exfat_mount(sb, p_pbr);
}
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-08-30 16:42 [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat Valdis Klētnieks
@ 2019-08-30 16:45 ` Christoph Hellwig
2019-08-31 0:48 ` Valdis Klētnieks
0 siblings, 1 reply; 20+ messages in thread
From: Christoph Hellwig @ 2019-08-30 16:45 UTC (permalink / raw)
To: Valdis Klētnieks
Cc: Greg Kroah-Hartman, Sasha Levin, Christoph Hellwig,
linux-fsdevel, linux-kernel
On Fri, Aug 30, 2019 at 12:42:39PM -0400, Valdis Klētnieks wrote:
> Concerns have been raised about the exfat driver accidentally mounting
> fat/vfat file systems. Add an extra configure option to help prevent that.
Just remove that code. This is exactly what I fear about this staging
crap, all kinds of half-a***ed patches instead of trying to get anything
done. Given that you signed up as the maintainer for this what is your
plan forward on it? What development did you on the code and what are
your next steps?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-08-30 16:45 ` Christoph Hellwig
@ 2019-08-31 0:48 ` Valdis Klētnieks
2019-08-31 6:46 ` Christoph Hellwig
0 siblings, 1 reply; 20+ messages in thread
From: Valdis Klētnieks @ 2019-08-31 0:48 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Greg Kroah-Hartman, Sasha Levin, linux-fsdevel, linux-kernel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1420 bytes --]
On Fri, 30 Aug 2019 09:45:03 -0700, Christoph Hellwig said:
> On Fri, Aug 30, 2019 at 12:42:39PM -0400, Valdis Klētnieks wrote:
> > Concerns have been raised about the exfat driver accidentally mounting
> > fat/vfat file systems. Add an extra configure option to help prevent that.
>
> Just remove that code. This is exactly what I fear about this staging
> crap, all kinds of half-a***ed patches instead of trying to get anything
Explain how it's half-a**ed. You worry about accidental mounting, meanwhile
down in the embedded space there are memory-constrained machines that
don't want separate vfat and exfat drivers sitting around in memory. If you
have a better patch that addresses both concerns, feel free to submit it.
> done. Given that you signed up as the maintainer for this what is your
> plan forward on it? What development did you on the code and what are
> your next steps?
Well, the *original* plan was to get it into the tree someplace so it can get
review and updates from others. Given the amount of press the Microsoft
announcement had, we were *hoping* there would be some momentum and
people actually looking at the code and feeding me patches. I've gotten a
half dozen already today....
Although if you prefer, it can just sit out-of-tree until I've got a perfect driver
without input or review from anybody. But I can't think of *any* instance where
that model has actually worked.
[-- Attachment #2: Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-08-31 0:48 ` Valdis Klētnieks
@ 2019-08-31 6:46 ` Christoph Hellwig
2019-08-31 10:25 ` Valdis Klētnieks
0 siblings, 1 reply; 20+ messages in thread
From: Christoph Hellwig @ 2019-08-31 6:46 UTC (permalink / raw)
To: Valdis Klētnieks
Cc: Christoph Hellwig, Greg Kroah-Hartman, Sasha Levin,
linux-fsdevel, linux-kernel
On Fri, Aug 30, 2019 at 08:48:36PM -0400, Valdis Klētnieks wrote:
> Explain how it's half-a**ed. You worry about accidental mounting, meanwhile
> down in the embedded space there are memory-constrained machines that
> don't want separate vfat and exfat drivers sitting around in memory. If you
> have a better patch that addresses both concerns, feel free to submit it.
Since when did Linux kernel submissions become "show me a better patch"
to reject something obviously bad?
As I said the right approach is to probably (pending comments from the
actual fat maintainer) to merge exfat support into the existing fs/fat/
codebase. You obviously seem to disagree (and at the same time not).
But using this as a pre-text of adding a non-disabled second fat16/32
implementation and actually allowing that to build with no reason is
just not how it works.
> > done. Given that you signed up as the maintainer for this what is your
> > plan forward on it? What development did you on the code and what are
> > your next steps?
>
> Well, the *original* plan was to get it into the tree someplace so it can get
> review and updates from others.
In other words you have no actual plan and no idea what to do and want to
rely on "others" to do anything, but at the same time reject the
comments from others how to do things right?
> Given the amount of press the Microsoft
> announcement had, we were *hoping* there would be some momentum and
> people actually looking at the code and feeding me patches. I've gotten a
> half dozen already today....
And all of that you can easily do by just sending out a patch series.
And maybe actually listening to comments.
> Although if you prefer, it can just sit out-of-tree until I've got a perfect driver
> without input or review from anybody. But I can't think of *any* instance where
> that model has actually worked.
You generally get a lot of review and comments by posting to the mailing
list. But what really helps is to just do the very basic homework
beforehand. And it also really helps to have a plan what you want to
do with a codebase you just copy and pasted from somewhere.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-08-31 6:46 ` Christoph Hellwig
@ 2019-08-31 10:25 ` Valdis Klētnieks
2019-08-31 14:24 ` Andy Shevchenko
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Valdis Klētnieks @ 2019-08-31 10:25 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Greg Kroah-Hartman, Sasha Levin, linux-fsdevel, linux-kernel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 28399 bytes --]
On Fri, 30 Aug 2019 23:46:16 -0700, Christoph Hellwig said:
> Since when did Linux kernel submissions become "show me a better patch"
> to reject something obviously bad?
Well, do you even have a *suggestion* for a better idea? Other than "just rip
it out"? Keeping in mind that:
> As I said the right approach is to probably (pending comments from the
> actual fat maintainer) to merge exfat support into the existing fs/fat/
> codebase. You obviously seem to disagree (and at the same time not).
At this point, there isn't any true consensus on whether that's the best
approach at the current. "Just rip it out" prevents following some directions
that people have voiced interest in. Now, if there was consensus that we
wanted a separate module that only did exfat, you'd be correct.
And just for the record, I've been around since the 2.5.47 or so kernel, and
I've seen *plenty* of times when somebody has submitted a better alternative
patch.
> But using this as a pre-text of adding a non-disabled second fat16/32
> implementation and actually allowing that to build with no reason is
> just not how it works.
Well.. let's see... It won't build unless you select CONFIG_STAGING. *And* you
select CONFIG_EXFAT_FS. *And* it wont mount anything other than exfat
unless you change CONFIG_EXFAT_DONT_MOUNT_VFAT
I think at that point, we can safely say that if it mounts a vfat filesystem,
it's because the person building the kernel has gone out of their way to
request that it do so.
Either that, or we have a major bug in kbuild. In general, kbuild doesn't build
things "for no reason".
Now, if what you want is "Please make it so the fat16/fat32 code is in separate
files that aren't built unless requested", that's in fact doable and a
reasonable request, and one that both doesn't conflict with anything other
directions we might want to go, and also prepares the code for more easy
separation if it's decided we really do want an exfat-only module.
> > > done. Given that you signed up as the maintainer for this what is your
> > > plan forward on it? What development did you on the code and what are
> > > your next steps?
> >
> > Well, the *original* plan was to get it into the tree someplace so it can get
> > review and updates from others.
>
> In other words you have no actual plan and no idea what to do and want to
> rely on "others" to do anything, but at the same time reject the
> comments from others how to do things right?
So far, the only comment I've rejected is one "just rip it out" that conflicts with
directions that others have indicated we may want to pursue.
And by the way, it seems like other filesystems rely on "others" to help out.
Let's look at the non-merge commit for fs/ext4. And these are actual patches,
not just reviewer comments....
(For those who don't feel like scrolling - 77.6% of the non-merge ext4 commits
are from a total of 463 somebodies other than Ted Ts'o)
Even some guy named Christoph Hellwig gave Ted Ts'o a bunch of help.
[/usr/src/linux-next] git log -- fs/ext4 | awk '/^commit/ {merge=0} /^Merge: / {merge=1} /^Author:/ { if (!merge) {print $0}}' | sort | uniq -c | sort -t: -k 1,1nr -k 2
718 Author: Theodore Ts'o <tytso@mit.edu>
260 Author: Jan Kara <jack@suse.cz>
151 Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
120 Author: Eric Sandeen <sandeen@redhat.com>
119 Author: Lukas Czerner <lczerner@redhat.com>
99 Author: Dmitry Monakhov <dmonakhov@openvz.org>
84 Author: Al Viro <viro@zeniv.linux.org.uk>
67 Author: Eric Biggers <ebiggers@google.com>
63 Author: Tao Ma <boyu.mt@taobao.com>
61 Author: Yongqiang Yang <xiaoqiangnk@gmail.com>
49 Author: Zheng Liu <wenqing.lz@taobao.com>
47 Author: Christoph Hellwig <hch@lst.de>
42 Author: Darrick J. Wong <darrick.wong@oracle.com>
40 Author: Tahsin Erdogan <tahsin@google.com>
36 Author: Mingming Cao <cmm@us.ibm.com>
32 Author: Eric Whitney <enwlinux@gmail.com>
28 Author: Christoph Hellwig <hch@infradead.org>
27 Author: Curt Wohlgemuth <curtw@google.com>
24 Author: Darrick J. Wong <djwong@us.ibm.com>
22 Author: Akira Fujita <a-fujita@rs.jp.nec.com>
20 Author: Ross Zwisler <zwisler@kernel.org>
18 Author: Eryu Guan <guaneryu@gmail.com>
16 Author: Vasily Averin <vvs@virtuozzo.com>
15 Author: Akinobu Mita <akinobu.mita@gmail.com>
15 Author: Allison Henderson <achender@linux.vnet.ibm.com>
15 Author: Robin Dong <sanbai@taobao.com>
14 Author: Dan Carpenter <dan.carpenter@oracle.com>
13 Author: Michael Halcrow <mhalcrow@google.com>
13 Author: Miklos Szeredi <mszeredi@suse.cz>
13 Author: Wang Shilong <wshilong@ddn.com>
12 Author: Daeho Jeong <daeho.jeong@samsung.com>
12 Author: Jan Kara <jack@suse.com>
12 Author: Joe Perches <joe@perches.com>
12 Author: Tejun Heo <tj@kernel.org>
11 Author: Jiaying Zhang <jiayingz@google.com>
11 Author: Namjae Jeon <namjae.jeon@samsung.com>
11 Author: Shen Feng <shen@cn.fujitsu.com>
10 Author: David Howells <dhowells@redhat.com>
10 Author: Guo Chao <yan@linux.vnet.ibm.com>
10 Author: Matthew Wilcox <willy@infradead.org>
9 Author: Alexey Dobriyan <adobriyan@gmail.com>
9 Author: Andreas Gruenbacher <agruenba@redhat.com>
9 Author: Fabian Frederick <fabf@skynet.be>
9 Author: Linus Torvalds <torvalds@linux-foundation.org>
8 Author: Amir Goldstein <amir73il@gmail.com>
8 Author: Amir Goldstein <amir73il@users.sf.net>
8 Author: Andrew Morton <akpm@linux-foundation.org>
8 Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
8 Author: Dan Williams <dan.j.williams@intel.com>
7 Author: Aditya Kali <adityakali@google.com>
7 Author: Al Viro <viro@ZenIV.linux.org.uk>
7 Author: Alex Tomas <alex@clusterfs.com>
7 Author: Arnd Bergmann <arnd@arndb.de>
7 Author: Colin Ian King <colin.king@canonical.com>
7 Author: Dave Jiang <dave.jiang@intel.com>
7 Author: Hugh Dickins <hugh@veritas.com>
7 Author: Kazuya Mio <k-mio@sx.jp.nec.com>
7 Author: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
7 Author: Zheng Liu <gnehzuil.liu@gmail.com>
7 Author: zhangyi (F) <yi.zhang@huawei.com>
6 Author: Anatol Pomozov <anatol.pomozov@gmail.com>
6 Author: Andreas Dilger <adilger@dilger.ca>
6 Author: Christoph Lameter <clameter@sgi.com>
6 Author: Dan Carpenter <error27@gmail.com>
6 Author: Duane Griffin <duaneg@dghda.com>
6 Author: Eric W. Biederman <ebiederm@xmission.com>
6 Author: Josef Bacik <jbacik@redhat.com>
6 Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
6 Author: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
6 Author: Li Zefan <lizf@cn.fujitsu.com>
6 Author: Mingming <cmm@us.ibm.com>
6 Author: Tyson Nottingham <tgnottingham@gmail.com>
5 Author: Andrew Morton <akpm@osdl.org>
5 Author: Avantika Mathur <mathur@us.ibm.com>
5 Author: Chandan Rajendra <chandan@linux.vnet.ibm.com>
5 Author: Frank Mayhar <fmayhar@google.com>
5 Author: Frederic Bohe <frederic.bohe@bull.net>
5 Author: Jose R. Santos <jrs@us.ibm.com>
5 Author: Kees Cook <keescook@chromium.org>
5 Author: Michal Hocko <mhocko@suse.com>
5 Author: Mike Christie <mchristi@redhat.com>
5 Author: Omar Sandoval <osandov@osandov.com>
5 Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
5 Author: Vegard Nossum <vegard.nossum@oracle.com>
5 Author: Wu Fengguang <fengguang.wu@intel.com>
5 Author: yangerkun <yangerkun@huawei.com>
4 Author: Amit Arora <aarora@in.ibm.com>
4 Author: Carlos Maiolino <cmaiolino@redhat.com>
4 Author: Chengguang Xu <cgxu519@gmx.com>
4 Author: Coly Li <i@coly.li>
4 Author: David Gstir <david@sigma-star.at>
4 Author: Djalal Harouni <tixxdz@opendz.org>
4 Author: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
4 Author: Jeff Layton <jlayton@kernel.org>
4 Author: Josef Bacik <josef@redhat.com>
4 Author: Li Xi <pkuelelixi@gmail.com>
4 Author: Manish Katiyar <mkatiyar@gmail.com>
4 Author: Miao Xie <miaoxie@huawei.com>
4 Author: Miklos Szeredi <mszeredi@redhat.com>
4 Author: Roel Kluin <roel.kluin@gmail.com>
4 Author: Toshi Kani <toshi.kani@hpe.com>
4 Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
4 Author: Valerie Clement <valerie.clement@bull.net>
4 Author: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com>
3 Author: Andi Kleen <andi@firstfloor.org>
3 Author: Azat Khuzhin <a3at.mail@gmail.com>
3 Author: Ben Hutchings <ben@decadent.org.uk>
3 Author: Chandan Rajendra <chandan@linux.ibm.com>
3 Author: Dave Chinner <dchinner@redhat.com>
3 Author: Eric Gouriou <egouriou@google.com>
3 Author: Eric Sandeen <sandeen@sandeen.net>
3 Author: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
3 Author: Gabriel Krisman Bertazi <krisman@collabora.com>
3 Author: H Hartley Sweeten <hartleys@visionengravers.com>
3 Author: Jaegeuk Kim <jaegeuk@kernel.org>
3 Author: Jeff Moyer <jmoyer@redhat.com>
3 Author: Jing Zhang <zj.barak@gmail.com>
3 Author: Julia Lawall <julia@diku.dk>
3 Author: Mathieu Malaterre <malat@debian.org>
3 Author: Maurizio Lombardi <mlombard@redhat.com>
3 Author: Nick Piggin <npiggin@kernel.dk>
3 Author: Nick Piggin <npiggin@suse.de>
3 Author: Nicolai Stange <nicstange@gmail.com>
3 Author: Nikolay Borisov <nborisov@suse.com>
3 Author: Pekka Enberg <penberg@cs.helsinki.fi>
3 Author: Peng Tao <bergwolf@gmail.com>
3 Author: Randy Dunlap <randy.dunlap@oracle.com>
3 Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
3 Author: Riccardo Schirone <sirmy15@gmail.com>
3 Author: Robin Dong <hao.bigrat@gmail.com>
3 Author: Thiemo Nagel <thiemo.nagel@ph.tum.de>
3 Author: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
3 Author: jon ernst <jonernst07@gmail.com>
2 Author: Adam Buchbinder <adam.buchbinder@gmail.com>
2 Author: Alexander Beregalov <a.beregalov@gmail.com>
2 Author: Alexandre Ratchov <alexandre.ratchov@bull.net>
2 Author: Andi Kleen <ak@linux.intel.com>
2 Author: Andi Kleen <ak@suse.de>
2 Author: Andreas Dilger <adilger@clusterfs.com>
2 Author: Andreas Dilger <adilger@sun.com>
2 Author: Andreas Dilger <andreas.dilger@intel.com>
2 Author: Andreas Gruenbacher <agruen@suse.de>
2 Author: Andrey Sidorov <qrxd43@motorola.com>
2 Author: André Goddard Rosa <andre.goddard@gmail.com>
2 Author: Ashish Sangwan <a.sangwan@samsung.com>
2 Author: Ashish Sangwan <ashishsangwan2@gmail.com>
2 Author: Badari Pulavarty <pbadari@us.ibm.com>
2 Author: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
2 Author: Boaz Harrosh <boaz@plexistor.com>
2 Author: Chao Yu <chao@kernel.org>
2 Author: Coly Li <coyli@suse.de>
2 Author: Dan Ehrenberg <dehrenberg@google.com>
2 Author: Daniel Mack <daniel@caiaq.de>
2 Author: Dave Hansen <haveblue@us.ibm.com>
2 Author: Dave Kleikamp <shaggy@austin.ibm.com>
2 Author: Deepa Dinamani <deepa.kernel@gmail.com>
2 Author: Dennis Zhou <dennis@kernel.org>
2 Author: Dmitry Monakhov <dmonakhov@sw.ru>
2 Author: Eric Paris <eparis@redhat.com>
2 Author: Eryu Guan <eguan@redhat.com>
2 Author: Fengguang Wu <wfg@mail.ustc.edu.cn>
2 Author: Goldwyn Rodrigues <rgoldwyn@suse.com>
2 Author: Herbert Xu <herbert@gondor.apana.org.au>
2 Author: Hisashi Hifumi <hifumi.hisashi@oss.ntt.co.jp>
2 Author: Ingo Molnar <mingo@kernel.org>
2 Author: Jakub Wilk <jwilk@jwilk.net>
2 Author: Jan Blunck <jblunck@infradead.org>
2 Author: Jan Blunck <jblunck@suse.de>
2 Author: Jens Axboe <axboe@fb.com>
2 Author: Jens Axboe <axboe@kernel.dk>
2 Author: Jens Axboe <jaxboe@fusionio.com>
2 Author: Jens Axboe <jens.axboe@oracle.com>
2 Author: Jie Liu <jeff.liu@oracle.com>
2 Author: Kalpak Shah <kalpak@clusterfs.com>
2 Author: Kent Overstreet <kmo@daterainc.com>
2 Author: Khazhismel Kumykov <khazhy@google.com>
2 Author: Kirill Tkhai <ktkhai@virtuozzo.com>
2 Author: Laurent Navet <laurent.navet@gmail.com>
2 Author: Marcin Slusarz <marcin.slusarz@gmail.com>
2 Author: Markus Elfring <elfring@users.sourceforge.net>
2 Author: Mel Gorman <mgorman@suse.de>
2 Author: Mel Gorman <mgorman@techsingularity.net>
2 Author: Ming Lei <ming.lei@canonical.com>
2 Author: Namhyung Kim <namhyung@gmail.com>
2 Author: Nikanth Karthikesan <knikanth@suse.de>
2 Author: Nikitas Angelinas <nikitasangelinas@gmail.com>
2 Author: Pan Bian <bianpan2016@163.com>
2 Author: Paul Bolle <pebolle@tiscali.nl>
2 Author: Richard Weinberger <richard@nod.at>
2 Author: Roel Kluin <12o3l@tiscali.nl>
2 Author: Roman Pen <roman.penyaev@profitbricks.com>
2 Author: Salman Qazi <sqazi@google.com>
2 Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
2 Author: Shaohua Li <shaohua.li@intel.com>
2 Author: Solofo Ramangalahy <Solofo.Ramangalahy@bull.net>
2 Author: Souptick Joarder <jrdr.linux@gmail.com>
2 Author: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
2 Author: Tobias Klauser <tklauser@distanz.ch>
2 Author: Vasily Averin <vvs@sw.ru>
2 Author: Vivek Haldar <haldar@google.com>
2 Author: Wang Sheng-Hui <shhuiw@gmail.com>
2 Author: Wei Yongjun <yjwei@cn.fujitsu.com>
2 Author: Yu Jian <yujian@whamcloud.com>
2 Author: Zhang Zhen <zhenzhang.zhang@huawei.com>
1 Author: Aaro Koskinen <aaro.koskinen@nokia.com>
1 Author: Adam Borowski <kilobyte@angband.pl>
1 Author: Adrian Bunk <bunk@kernel.org>
1 Author: Adrian Bunk <bunk@stusta.de>
1 Author: Aihua Zhang <zhangaihua1@huawei.com>
1 Author: Akria Fujita <a-fujita@rs.jp.nec.com>
1 Author: Alan Cox <alan@linux.intel.com>
1 Author: Ales Novak <alnovak@suse.cz>
1 Author: Alessio Igor Bogani <abogani@texware.it>
1 Author: Alexander V. Lukyanov <lav@netis.ru>
1 Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
1 Author: Amerigo Wang <amwang@redhat.com>
1 Author: Amir G <amir73il@users.sourceforge.net>
1 Author: Anand Gadiyar <gadiyar@ti.com>
1 Author: Andi Shyti <andi@etezian.org>
1 Author: Andrea Arcangeli <aarcange@redhat.com>
1 Author: Andreas Dilger <adilger@whamcloud.com>
1 Author: Andreas Schlick <schlick@lavabit.com>
1 Author: Andrew Perepechko <andrew.perepechko@seagate.com>
1 Author: Andrey Savochkin <saw@sw.ru>
1 Author: Andrey Tsyvarev <tsyvarev@ispras.ru>
1 Author: Andries E. Brouwer <Andries.Brouwer@cwi.nl>
1 Author: Andy Leiserson <andy@leiserson.org>
1 Author: Andy Lutomirski <luto@amacapital.net>
1 Author: Andy Lutomirski <luto@kernel.org>
1 Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
1 Author: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
1 Author: Anton Protopopov <a.s.protopopov@gmail.com>
1 Author: Arjan van de Ven <arjan@linux.intel.com>
1 Author: Artem Blagodarenko <artem.blagodarenko@gmail.com>
1 Author: Barret Rhoden <brho@google.com>
1 Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
1 Author: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
1 Author: Bobi Jam <bobijam@whamcloud.com>
1 Author: Borislav Petkov <bbpetkov@yahoo.de>
1 Author: BoxiLiu <lewis.liulei@huawei.com>
1 Author: Brian Foster <bfoster@redhat.com>
1 Author: Bryan Donlan <bdonlan@gmail.com>
1 Author: Chanho Park <parkch98@gmail.com>
1 Author: Chen Gang <gang.chen.5i5j@gmail.com>
1 Author: Chen Gang <gang.chen@asianux.com>
1 Author: Christian Borntraeger <borntraeger@de.ibm.com>
1 Author: Christoph Lameter <cl@linux-foundation.org>
1 Author: Christoph Lameter <cl@linux.com>
1 Author: Chuck Ebbert <cebbert@redhat.com>
1 Author: Cody P Schafer <cody@linux.vnet.ibm.com>
1 Author: Coly Li <colyli@gmail.com>
1 Author: Cong Ding <dinggnu@gmail.com>
1 Author: Cyrill Gorcunov <gorcunov@gmail.com>
1 Author: Damien Guibouret <damien.guibouret@partition-saving.com>
1 Author: Dan Magenheimer <dan.magenheimer@oracle.com>
1 Author: Dave Jones <davej@redhat.com>
1 Author: David Moore <dmoorefo@gmail.com>
1 Author: David Turner <novalis@novalis.org>
1 Author: David Windsor <dave@nullcore.net>
1 Author: Davide Italiano <dccitaliano@gmail.com>
1 Author: Debabrata Banerjee <dbanerje@akamai.com>
1 Author: Denis V. Lunev <den@openvz.org>
1 Author: Dennis Zhou (Facebook) <dennisszhou@gmail.com>
1 Author: Dmitri Monakho <dmonakhov@openvz.org>
1 Author: Dmitriy Monakhov <dmonakhov@openvz.org>
1 Author: Dmitriy Monakhov <dmonakhov@sw.ru>
1 Author: Dmitry Mishin <dim@openvz.org>
1 Author: Dr. Tilmann Bubeck <t.bubeck@reinform.de>
1 Author: Eldad Zack <eldad@fogrefinery.com>
1 Author: Emese Revfy <re.emese@gmail.com>
1 Author: Emoly Liu <emoly.liu@intel.com>
1 Author: Eric Dumazet <dada1@cosmosbay.com>
1 Author: Eric Engestrom <eric.engestrom@imgtec.com>
1 Author: Eric Sesterhenn <snakebyte@gmx.de>
1 Author: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
1 Author: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>
1 Author: Fabrice Jouhaud <yargil@free.fr>
1 Author: Fan Yong <yong.fan@whamcloud.com>
1 Author: Feng Tang <feng.tang@intel.com>
1 Author: Fengguang Wu <fengguang.wu@gmail.com>
1 Author: Forrest Liu <forrestl@synology.com>
1 Author: From: Thiemo Nagel <thiemo.nagel@ph.tum.de>
1 Author: Geert Uytterhoeven <geert+renesas@glider.be>
1 Author: Geliang Tang <geliangtang@163.com>
1 Author: Giedrius Rekasius <giedrius.rekasius@gmail.com>
1 Author: Gioh Kim <gioh.kim@lge.com>
1 Author: Girish Shilamkar <girish@clusterfs.com>
1 Author: Goffredo Baroncelli <kreijack@inwind.it>
1 Author: Greg Harm <gharm@google.com>
1 Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1 Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
1 Author: Haibo Liu <HaiboLiu6@gmai.com>
1 Author: HaiboLiu <HaiboLiu6@gmail.com>
1 Author: Haogang Chen <haogangchen@gmail.com>
1 Author: Harshad Shirwadkar <harshads@google.com>
1 Author: Harvey Harrison <harvey.harrison@gmail.com>
1 Author: Heiko Carstens <heiko.carstens@de.ibm.com>
1 Author: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
1 Author: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com>
1 Author: Huaitong Han <huaitong.han@intel.com>
1 Author: Huang Weiyi <weiyi.huang@gmail.com>
1 Author: Hugh Dickins <hughd@google.com>
1 Author: Ingo Molnar <mingo@elte.hu>
1 Author: Insu Yun <wuninsu@gmail.com>
1 Author: J. Bruce Fields <bfields@redhat.com>
1 Author: Jan Mrazek <email@honzamrazek.cz>
1 Author: Jason A. Donenfeld <Jason@zx2c4.com>
1 Author: Jason Yan <yanaijie@huawei.com>
1 Author: Jean Delvare <jdelvare@suse.de>
1 Author: Jean Delvare <khali@linux-fr.org>
1 Author: Jean Noel Cordenner <jean-noel.cordenner@bull.net>
1 Author: Jeremy Cline <jcline@redhat.com>
1 Author: Jerry Lee <jerrylee@qnap.com>
1 Author: Jesper Dangaard Brouer <hawk@comx.dk>
1 Author: Jesper Juhl <jj@chaosbits.net>
1 Author: Jiri Slaby <jslaby@suse.cz>
1 Author: Jiufei Xue <jiufei.xue@linux.alibaba.com>
1 Author: Johann Lombardi <johann.lombardi@bull.net>
1 Author: Johann Lombardi <johann@Sun.COM>
1 Author: Johann Lombardi <johann@whamcloud.com>
1 Author: Johannes Weiner <hannes@cmpxchg.org>
1 Author: John Stultz <john.stultz@linaro.org>
1 Author: Jon Derrick <jonathan.derrick@intel.com>
1 Author: Jon Ernst <jonernst07@gmx.com>
1 Author: Josef "Jeff" Sipek <jsipek@cs.sunysb.edu>
1 Author: Josef 'Jeff' Sipek <jsipek@cs.sunysb.edu>
1 Author: Josef Bacik <jbacik@fb.com>
1 Author: Julia Lawall <Julia.Lawall@lip6.fr>
1 Author: Jun Piao <piaojun@huawei.com>
1 Author: Junho Ryu <jayr@google.com>
1 Author: Junichi Uekawa <uekawa@google.com>
1 Author: Justin P. Mattock <justinmattock@gmail.com>
1 Author: Kaho Ng <ngkaho1234@gmail.com>
1 Author: Kalpak Shah <kalpak.shah@sun.com>
1 Author: Kent Overstreet <kent.overstreet@gmail.com>
1 Author: Kent Overstreet <koverstreet@google.com>
1 Author: Kimberly Brown <kimbrownkd@gmail.com>
1 Author: Kirill Korotaev <dev@openvz.org>
1 Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
1 Author: Lachlan McIlroy <lmcilroy@redhat.com>
1 Author: Laurent Vivier <Laurent.Vivier@bull.net>
1 Author: Leonard Michlmayr <leonard.michlmayr@gmail.com>
1 Author: Li Dongyang <dongyangli@ddn.com>
1 Author: Linus Torvalds <torvalds@woody.linux-foundation.org>
1 Author: Liu Song <liu.song11@zte.com.cn>
1 Author: Liu Xiang <liu.xiang6@zte.com.cn>
1 Author: Lucas De Marchi <lucas.demarchi@profusion.mobi>
1 Author: Luis R. Rodriguez <mcgrof@kernel.org>
1 Author: Maarten ter Huurne <maarten@treewalker.org>
1 Author: Maciej Żenczykowski <zenczykowski@gmail.com>
1 Author: Maninder Singh <maninder1.s@samsung.com>
1 Author: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
1 Author: Markus Rechberger <Markus.Rechberger@amd.com>
1 Author: Markus Trippelsdorf <markus@trippelsdorf.de>
1 Author: Martin K. Petersen <martin.petersen@oracle.com>
1 Author: Masahiro Yamada <yamada.masahiro@socionext.com>
1 Author: Mathias Krause <minipli@googlemail.com>
1 Author: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
1 Author: Matt LaPlante <kernel1@cyberdogtech.com>
1 Author: Matthew Garrett <mjg59@google.com>
1 Author: Maxim Patlasov <MPatlasov@parallels.com>
1 Author: Maxim Patlasov <maxim.patlasov@gmail.com>
1 Author: Miao Xie <miaox@cn.fujitsu.com>
1 Author: Michael Callahan <michaelcallahan@fb.com>
1 Author: Michael Tokarev <mjt@tls.msk.ru>
1 Author: Michal Hocko <mhocko@suse.cz>
1 Author: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
1 Author: Mike Snitzer <snitzer@gmail.com>
1 Author: Mikulas Patocka <mikulas@twibright.com>
1 Author: Mimi Zohar <zohar@linux.vnet.ibm.com>
1 Author: Ming Lei <ming.lei@redhat.com>
1 Author: Namjae Jeon <linkinjeon@gmail.com>
1 Author: Nicolas Kaiser <nikai@nikai.net>
1 Author: Nikolay Borisov <kernel@kyup.com>
1 Author: Niu Yawei <yawei.niu@gmail.com>
1 Author: Pankaj Gupta <pagupta@redhat.com>
1 Author: Patrick J. LoPresti <lopresti@gmail.com>
1 Author: Patrick Palka <patrick@parcs.ath.cx>
1 Author: Paul Gortmaker <paul.gortmaker@windriver.com>
1 Author: Paul Mackerras <paulus@samba.org>
1 Author: Paul Mundt <lethal@linux-sh.org>
1 Author: Paul Taysom <taysom@chromium.org>
1 Author: Peter Huewe <peterhuewe@gmx.de>
1 Author: Peter Zijlstra <peterz@infradead.org>
1 Author: Petros Koutoupis <petros@petroskoutoupis.com>
1 Author: Philippe De Muyter <phdm@macqel.be>
1 Author: Piotr Sarna <p.sarna@partner.samsung.com>
1 Author: Pranay Kr. Srivastava <pranjas@gmail.com>
1 Author: Rakesh Pandit <rakesh@tuxera.com>
1 Author: Randy Dodgen <dodgen@google.com>
1 Author: Randy Dunlap <rdunlap@infradead.org>
1 Author: Richard Kennedy <richard@rsk.demon.co.uk>
1 Author: Robert P. J. Day <rpjday@mindspring.com>
1 Author: Ross Zwisler <zwisler@chromium.org>
1 Author: Rusty Russell <rusty@rustcorp.com.au>
1 Author: Sachin Kamat <sachin.kamat@linaro.org>
1 Author: Sahitya Tummala <stummala@codeaurora.org>
1 Author: Santosh Nayak <santoshprasadnayak@gmail.com>
1 Author: Satyam Sharma <ssatyam@cse.iitk.ac.in>
1 Author: Sean Fu <fxinrong@gmail.com>
1 Author: Serge E. Hallyn <serge@hallyn.com>
1 Author: Sergey Karamov <skaramov@google.com>
1 Author: Seth Forshee <seth.forshee@canonical.com>
1 Author: Seunghun Lee <waydi1@gmail.com>
1 Author: Sheng Yong <shengyong1@huawei.com>
1 Author: Shi Siyuan <shisiyuan@xiaomi.com>
1 Author: Simon Ruderich <simon@ruderich.org>
1 Author: Solofo.Ramangalahy@bull.net <>
1 Author: Sriram Rajagopalan <sriramr@arista.com>
1 Author: Stephen Hemminger <shemminger@vyatta.com>
1 Author: Stephen Hemminger <stephen@networkplumber.org>
1 Author: Steven Liu <lingjiujianke@gmail.com>
1 Author: Steven Whitehouse <swhiteho@redhat.com>
1 Author: Stoyan Gaydarov <stoyboyker@gmail.com>
1 Author: Suparna Bhattacharya <suparna@in.ibm.com>
1 Author: Surbhi Palande <surbhi.palande@canonical.com>
1 Author: T Makphaibulchoke <tmac@hp.com>
1 Author: Takashi Sato <sho@tnes.nec.co.jp>
1 Author: Takashi Sato <t-sato@yk.jp.nec.com>
1 Author: Tao Ma <tao.ma@oracle.com>
1 Author: Theodore Tso <tytso@MIT.EDU>
1 Author: Thomas Gleixner <tglx@linutronix.de>
1 Author: Tiger Yang <tiger.yang@oracle.com>
1 Author: Tim Schmielau <tim@physik3.uni-rostock.de>
1 Author: Utako Kusaka <u-kusaka@wm.jp.nec.com>
1 Author: Vahram Martirosyan <vmartirosyan@gmail.com>
1 Author: Valerie Aurora <val@vaaconsulting.com>
1 Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
1 Author: Vignesh Babu <vignesh.babu@wipro.com>
1 Author: Vincent Minet <vincent@vincent-minet.net>
1 Author: Viresh Kumar <viresh.kumar@linaro.org>
1 Author: Vladimir Davydov <vdavydov.dev@gmail.com>
1 Author: Wang Sheng-Hui <crosslonelyover@gmail.com>
1 Author: Wang Shilong <wangshilong1991@gmail.com>
1 Author: Wang Shilong <wangsl-fnst@cn.fujitsu.com>
1 Author: Wei Yuan <weiyuan.wei@huawei.com>
1 Author: Xi Wang <xi.wang@gmail.com>
1 Author: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com>
1 Author: Xu Cang <cangxumu@gmail.com>
1 Author: Yan, Zheng <zheng.z.yan@intel.com>
1 Author: Yang Ruirui <ruirui.r.yang@tieto.com>
1 Author: Yaowei Bai <bywxiaobai@163.com>
1 Author: Yasunori Goto <y-goto@jp.fujitsu.com>
1 Author: Younger Liu <younger.liucn@gmail.com>
1 Author: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
1 Author: Zhao Hongjiang <zhaohongjiang@huawei.com>
1 Author: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
1 Author: Zhouyi Zhou <zhouzhouyi@gmail.com>
1 Author: boxi liu <boxi10liu@gmail.com>
1 Author: gmail <yngsion@gmail.com>
1 Author: harshads <harshads@google.com>
1 Author: jiayingz@google.com (Jiaying Zhang) <>
1 Author: jon ernst <jonernst07@gmx.com>
1 Author: liang xie <xieliang007@gmail.com>
1 Author: piaojun <piaojun@huawei.com>
1 Author: ruippan (潘ç¿) <ruippan@tencent.com>
1 Author: vignesh babu <vignesh.babu@wipro.com>
1 Author: vikram.jadhav07 <vikramjadhavpucsd2007@gmail.com>
1 Author: wangguang <wang.guang55@zte.com.cn>
1 Author: yalin wang <yalin.wang2010@gmail.com>
1 Author: zhangjs <zachary@baishancloud.com>
1 Author: zhenwei.pi <zhenwei.pi@youruncloud.com>
1 Author: zhong jiang <zhongjiang@huawei.com>
1 Author: zilong.liu <liuziloong@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-08-31 10:25 ` Valdis Klētnieks
@ 2019-08-31 14:24 ` Andy Shevchenko
2019-08-31 14:51 ` Valdis Klētnieks
2019-09-01 1:07 ` Dave Chinner
2019-09-02 7:35 ` Christoph Hellwig
2 siblings, 1 reply; 20+ messages in thread
From: Andy Shevchenko @ 2019-08-31 14:24 UTC (permalink / raw)
To: Valdis Klētnieks
Cc: Christoph Hellwig, Greg Kroah-Hartman, Sasha Levin,
Linux FS Devel, Linux Kernel Mailing List
On Sat, Aug 31, 2019 at 1:26 PM Valdis Klētnieks
<valdis.kletnieks@vt.edu> wrote:
> [/usr/src/linux-next] git log -- fs/ext4 | awk '/^commit/ {merge=0} /^Merge: / {merge=1} /^Author:/ { if (!merge) {print $0}}' | sort | uniq -c | sort -t: -k 1,1nr -k 2
Side note:
% git shortlog -n --no-merges -- fs/ext4 | grep '^[^ ]'
kinda faster and groups by name.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-08-31 14:24 ` Andy Shevchenko
@ 2019-08-31 14:51 ` Valdis Klētnieks
0 siblings, 0 replies; 20+ messages in thread
From: Valdis Klētnieks @ 2019-08-31 14:51 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Christoph Hellwig, Greg Kroah-Hartman, Sasha Levin,
Linux FS Devel, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 303 bytes --]
On Sat, 31 Aug 2019 17:24:47 +0300, Andy Shevchenko said:
> Side note:
>
> % git shortlog -n --no-merges -- fs/ext4 | grep '^[^ ]'
>
> kinda faster and groups by name.
Thanks... I rarely do statistical analyses of this sort of thing, so 'git
shortlog' isn't on my list of most-used git subcommands...
[-- Attachment #2: Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-08-31 10:25 ` Valdis Klētnieks
2019-08-31 14:24 ` Andy Shevchenko
@ 2019-09-01 1:07 ` Dave Chinner
2019-09-01 1:37 ` Gao Xiang
2019-09-01 3:37 ` Valdis Klētnieks
2019-09-02 7:35 ` Christoph Hellwig
2 siblings, 2 replies; 20+ messages in thread
From: Dave Chinner @ 2019-09-01 1:07 UTC (permalink / raw)
To: Valdis Klētnieks
Cc: Christoph Hellwig, Greg Kroah-Hartman, Sasha Levin,
linux-fsdevel, linux-kernel
On Sat, Aug 31, 2019 at 06:25:21AM -0400, Valdis Klētnieks wrote:
> On Fri, 30 Aug 2019 23:46:16 -0700, Christoph Hellwig said:
> > Since when did Linux kernel submissions become "show me a better patch"
> > to reject something obviously bad?
>
> Well, do you even have a *suggestion* for a better idea? Other than "just rip
> it out"? Keeping in mind that:
>
> > As I said the right approach is to probably (pending comments from the
> > actual fat maintainer) to merge exfat support into the existing fs/fat/
> > codebase. You obviously seem to disagree (and at the same time not).
>
> At this point, there isn't any true consensus on whether that's the best
> approach at the current.
Which, quite frankly, means it has been merged prematurely.
Valdis - the model for getting a new filesystem merged is the one
taken by Orangefs. That was not merged through the staging tree,
it was reviewd via patches to linux-fsdevel that were iterated far
faster than the stable merge cycle allows, allowed all the cleanups
to be done independently of the feature work needed, the structural
changes we easy to discuss, quote, etc.
These are the sorts of problems we are having with EROFS right now,
even though it's been in staging for some time, and it's clear we
are already having them with exfat - fundamental architecture issues
have not yet been decided, and so there's likely major structural
change yet to be done.
That's stuff that is much more easily done and reveiwed by patches
on a mailing list. You don't need the code in the staging tree to
get this sort of thing done and, really, having it already merged
gets in the way of doing major structural change as it cannot be
rapidly iterated independently of the kernel dev cycle...
So when Christoph say:
> "Just rip it out"
what he is really saying is that Greg has jumped the jump and is -
yet again - fucking over filesystem developers because he's
taken the review process for a new filesystem out of hands _yet
again_.
He did this with POHMELFS, then Lustre, then EROFS - they all got
merged into stable over the objections of senior filesystem
developers. The first two were an utter disaster, the latter is
rapidly turning into one.
You wanted a "show me a better patch" response from Christoph. What
he actually is saying is "we've got a better process for reviewing
and merging filesystems". That is, we need to reboot the exfat
process from the start - sort out the fundamental implementation
direction and then implement via the normal out-of-tree patch series
iteration process.
That's the fundamental problem here - we have a rogue maintainer
that is abusing their power by subverting our normal review and
merge process. I don't know (or care) what motive that maintainer
has for expedited merging of this filesystem, but history tells us
it _will_ result in a total clusterfuck in the near future. In fact,
I'd argue that the clusterfuck has already arrived....
> And by the way, it seems like other filesystems rely on "others" to help out.
> Let's look at the non-merge commit for fs/ext4. And these are actual patches,
> not just reviewer comments....
Totally irrelevant to the issue at hand. You can easily co-ordinate
out of tree contributions through a github tree, or a tree on
kernel.org, etc.
Being in the staging tree does not get you more robust review -
it'll just delay it until someone wants it out of the staging tree,
and then you'll get all the same issues with experienced filesystem
developer review as you are getting now.
That's the choice you have to make now: listen to the reviewers
saying "resolve the fundamental issues before goign any further",
or you can ignore that and have it rejected after another year of
work because the fundamental issues haven't been resolved while it
sits in staging....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-09-01 1:07 ` Dave Chinner
@ 2019-09-01 1:37 ` Gao Xiang
2019-09-01 3:05 ` Al Viro
2019-09-01 3:37 ` Valdis Klētnieks
1 sibling, 1 reply; 20+ messages in thread
From: Gao Xiang @ 2019-09-01 1:37 UTC (permalink / raw)
To: Dave Chinner
Cc: Valdis Klētnieks, Christoph Hellwig, Greg Kroah-Hartman,
Sasha Levin, linux-fsdevel, linux-kernel
Hi Dave,
On Sun, Sep 01, 2019 at 11:07:21AM +1000, Dave Chinner wrote:
> On Sat, Aug 31, 2019 at 06:25:21AM -0400, Valdis Kl??tnieks wrote:
> > On Fri, 30 Aug 2019 23:46:16 -0700, Christoph Hellwig said:
> > > Since when did Linux kernel submissions become "show me a better patch"
> > > to reject something obviously bad?
> >
> > Well, do you even have a *suggestion* for a better idea? Other than "just rip
> > it out"? Keeping in mind that:
> >
> > > As I said the right approach is to probably (pending comments from the
> > > actual fat maintainer) to merge exfat support into the existing fs/fat/
> > > codebase. You obviously seem to disagree (and at the same time not).
> >
> > At this point, there isn't any true consensus on whether that's the best
> > approach at the current.
>
> Which, quite frankly, means it has been merged prematurely.
>
> Valdis - the model for getting a new filesystem merged is the one
> taken by Orangefs. That was not merged through the staging tree,
> it was reviewd via patches to linux-fsdevel that were iterated far
> faster than the stable merge cycle allows, allowed all the cleanups
> to be done independently of the feature work needed, the structural
> changes we easy to discuss, quote, etc.
fs/orangefs/dir.c
61 static int do_readdir(struct orangefs_inode_s *oi,
62 struct orangefs_dir *od, struct dentry *dentry,
63 struct orangefs_kernel_op_s *op)
131 static int parse_readdir(struct orangefs_dir *od,
132 struct orangefs_kernel_op_s *op)
189 static int fill_from_part(struct orangefs_dir_part *part,
190 struct dir_context *ctx)
fs/orangefs/file.c
19 static int flush_racache(struct inode *inode)
48 ssize_t wait_for_direct_io(enum ORANGEFS_io_type type, struct inode *inode,
49 loff_t *offset, struct iov_iter *iter, size_t total_size,
50 loff_t readahead_size, struct orangefs_write_range *wr, int *index_return)
fs/orangefs/super.c
304
305 int fsid_key_table_initialize(void)
306 {
307 return 0;
308 }
309
310 void fsid_key_table_finalize(void)
311 {
312 }
----> no prefix and empty functions
fs/orangefs/xattr.c
31 static int is_reserved_key(const char *key, size_t size)
40 static inline int convert_to_internal_xattr_flags(int setxattr_flags)
54 static unsigned int xattr_key(const char *key)
>
> These are the sorts of problems we are having with EROFS right now,
> even though it's been in staging for some time, and it's clear we
> are already having them with exfat - fundamental architecture issues
> have not yet been decided, and so there's likely major structural
> change yet to be done.
>
> That's stuff that is much more easily done and reveiwed by patches
> on a mailing list. You don't need the code in the staging tree to
> get this sort of thing done and, really, having it already merged
> gets in the way of doing major structural change as it cannot be
> rapidly iterated independently of the kernel dev cycle...
>
> So when Christoph say:
>
> > "Just rip it out"
>
> what he is really saying is that Greg has jumped the jump and is -
> yet again - fucking over filesystem developers because he's
> taken the review process for a new filesystem out of hands _yet
> again_.
>
> He did this with POHMELFS, then Lustre, then EROFS - they all got
> merged into stable over the objections of senior filesystem
> developers. The first two were an utter disaster, the latter is
> rapidly turning into one.
I don't know what "rapidly turning" means:
This round I am working on all suggestions from fs developers;
and I have been addressing what Christoph said for days, he hope that
all functions should be prefixed with "erofs_" and I am doing.
That is all.
Thanks,
Gao Xiang
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-09-01 1:37 ` Gao Xiang
@ 2019-09-01 3:05 ` Al Viro
2019-09-01 3:26 ` Gao Xiang
0 siblings, 1 reply; 20+ messages in thread
From: Al Viro @ 2019-09-01 3:05 UTC (permalink / raw)
To: Gao Xiang
Cc: Dave Chinner, Valdis Klētnieks, Christoph Hellwig,
Greg Kroah-Hartman, Sasha Levin, linux-fsdevel, linux-kernel
On Sun, Sep 01, 2019 at 09:37:19AM +0800, Gao Xiang wrote:
> fs/orangefs/file.c
> 19 static int flush_racache(struct inode *inode)
Just why the hell would _that_ one be a problem? It's static in
file; it can't pollute the namespace even if linked into the
kernel.
Folks, let's keep at least some degree of sanity - this is sinking
to the level of certain killfile denizens...
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-09-01 3:05 ` Al Viro
@ 2019-09-01 3:26 ` Gao Xiang
0 siblings, 0 replies; 20+ messages in thread
From: Gao Xiang @ 2019-09-01 3:26 UTC (permalink / raw)
To: Al Viro
Cc: Dave Chinner, Valdis Klētnieks, Christoph Hellwig,
Greg Kroah-Hartman, Sasha Levin, linux-fsdevel, linux-kernel
Hi Al,
On Sun, Sep 01, 2019 at 04:05:14AM +0100, Al Viro wrote:
> On Sun, Sep 01, 2019 at 09:37:19AM +0800, Gao Xiang wrote:
>
> > fs/orangefs/file.c
> > 19 static int flush_racache(struct inode *inode)
>
> Just why the hell would _that_ one be a problem? It's static in
> file; it can't pollute the namespace even if linked into the
> kernel.
>
> Folks, let's keep at least some degree of sanity - this is sinking
> to the level of certain killfile denizens...
Thanks for your kind reply. I think in the same way.
And Christoph did many great suggestions for erofs, thanks him
for erofs, and I'm already fixed most of them, and some
suggestions I have no idea to do....
1) add "erofs_" to all functions [1] [2];
2) avoid sb_bread and use read_mapping_page, actually
read_mapping_page will call block_read_full_page and
buffer_heads still there;
and I don't know what erofs "rapidly turning" means, all great
suggestions I can fix them all, I have no idea it's a bad thing.
[1] https://lore.kernel.org/linux-fsdevel/20190830163910.GB29603@infradead.org/
[2] https://lore.kernel.org/linux-fsdevel/20190831064853.GA162401@architecture4/
Thanks,
Gao Xiang
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-09-01 1:07 ` Dave Chinner
2019-09-01 1:37 ` Gao Xiang
@ 2019-09-01 3:37 ` Valdis Klētnieks
2019-09-01 22:43 ` Dave Chinner
1 sibling, 1 reply; 20+ messages in thread
From: Valdis Klētnieks @ 2019-09-01 3:37 UTC (permalink / raw)
To: Dave Chinner
Cc: Christoph Hellwig, Greg Kroah-Hartman, Sasha Levin,
linux-fsdevel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]
On Sun, 01 Sep 2019 11:07:21 +1000, Dave Chinner said:
> Totally irrelevant to the issue at hand. You can easily co-ordinate
> out of tree contributions through a github tree, or a tree on
> kernel.org, etc.
Well.. I'm not personally wedded to the staging tree. I'm just interested in
getting a driver done and upstreamed with as little pain as possible. :)
Is there any preference for github versus kernel.org? I can set up a github
tree on my own, no idea who needs to do what for a kernel.org tree.
Also, this (from another email of yours) was (at least to me) the most useful
thing said so far:
> look at what other people have raised w.r.t. to that filesystem -
> on-disk format validation, re-implementation of largely generic
> code, lack of namespacing of functions leading to conflicts with
> generic/VFS functionality, etc.
All of which are now on the to-do list, thanks.
Now one big question:
Should I heave all the vfat stuff overboard and make a module that
*only* does exfat, or is there enough interest in an extended FAT module
that does vfat and extfat, in which case the direction should be to re-align
this module's code with vfat?
> That's the choice you have to make now: listen to the reviewers
> saying "resolve the fundamental issues before goign any further",
Well... *getting* a laundry list of what the reviewers see as the fundamental
issues is the first step in resolving them ;)
[-- Attachment #2: Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-09-01 3:37 ` Valdis Klētnieks
@ 2019-09-01 22:43 ` Dave Chinner
2019-09-01 23:13 ` Valdis Klētnieks
0 siblings, 1 reply; 20+ messages in thread
From: Dave Chinner @ 2019-09-01 22:43 UTC (permalink / raw)
To: Valdis Klētnieks
Cc: Christoph Hellwig, Greg Kroah-Hartman, Sasha Levin,
linux-fsdevel, linux-kernel
On Sat, Aug 31, 2019 at 11:37:27PM -0400, Valdis Klētnieks wrote:
> On Sun, 01 Sep 2019 11:07:21 +1000, Dave Chinner said:
> > Totally irrelevant to the issue at hand. You can easily co-ordinate
> > out of tree contributions through a github tree, or a tree on
> > kernel.org, etc.
>
> Well.. I'm not personally wedded to the staging tree. I'm just interested in
> getting a driver done and upstreamed with as little pain as possible. :)
Understood - I'm trying to head off you guys getting delayed
by sitting for a year in the staging tree polishing a turd and not
addressing the things that really need to be done first...
> Is there any preference for github versus kernel.org? I can set up a github
> tree on my own, no idea who needs to do what for a kernel.org tree.
What ever is most convenient for you to manage and co-ordinate. :P
> Also, this (from another email of yours) was (at least to me) the most useful
> thing said so far:
>
> > look at what other people have raised w.r.t. to that filesystem -
> > on-disk format validation, re-implementation of largely generic
> > code, lack of namespacing of functions leading to conflicts with
> > generic/VFS functionality, etc.
>
> All of which are now on the to-do list, thanks.
>
> Now one big question:
>
> Should I heave all the vfat stuff overboard and make a module that
> *only* does exfat, or is there enough interest in an extended FAT module
> that does vfat and extfat, in which case the direction should be to re-align
> this module's code with vfat?
I don't know the details of the exfat spec or the code to know what
the best approach is. I've worked fairly closely with Christoph for
more than a decade - you need to think about what he says rather
than /how he says it/ because there's a lot of thought and knowledge
behind his reasoning. Hence if I were implementing exfat and
Christoph was saying "throw it away and extend fs/fat"
then that's what I'd be doing.
A lot of this is largely risk management - there's a good chance
that the people developing the code move on after the project is
done and merged, which leaves the people like Christoph with the
burden of long term code maintenance for that filesystem. There's
enough crusty, old, largely unmaintained filesystem code already,
and we don't want more. Implementing exfat on top of fs/fat kills
two birds with one stone - it modernises the fs/fat code base and
brings new functionality that will have more developers interested
in maintaining it over the long term. So from an overall filesystem
maintenance perspective, building on top of fs/fat makes a lot of
sense to a kernel filesystem developer...
This is not a judgement on the quality of the existing exfat code
or it's developers - it's just that there are very good reasons for
building on existing codebase rather than creating a whole new code
base that has very similar functionality.
That's my total involvement in this - I don't really care about
exfat at all - my stake in this is to improve the development,
review and merge process being undertaken. We have a history of lax
review, poor processes and really shitty code being merged into the
kernel and I've been on the cleanup squad for a few of them over the
past couple of years. That's a burnout vector, so it's in the
interests of my own sanity (and fs developers) to set standards and
precedence to prevent more trainwrecks from happening before the
train even leaves the station...
> > That's the choice you have to make now: listen to the reviewers
> > saying "resolve the fundamental issues before goign any further",
>
> Well... *getting* a laundry list of what the reviewers see as the fundamental
> issues is the first step in resolving them ;)
You won't get them all at once. You'll get something new every round
of review as the bigger issues are worked out, the reviewers become
more familiar with the code and notice more detailed/subtle
issues. Most filesystem reviews start with developers trying to
understand the on-disk structure and architecture rather that focus
on whitespace and code cleanliness. Cleaning up the code can be done
after we work through all the structural issues...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-09-01 22:43 ` Dave Chinner
@ 2019-09-01 23:13 ` Valdis Klētnieks
2019-09-02 7:38 ` Christoph Hellwig
0 siblings, 1 reply; 20+ messages in thread
From: Valdis Klētnieks @ 2019-09-01 23:13 UTC (permalink / raw)
To: Dave Chinner
Cc: Christoph Hellwig, Greg Kroah-Hartman, Sasha Levin,
linux-fsdevel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]
On Mon, 02 Sep 2019 08:43:29 +1000, Dave Chinner said:
> I don't know the details of the exfat spec or the code to know what
> the best approach is. I've worked fairly closely with Christoph for
> more than a decade - you need to think about what he says rather
> than /how he says it/ because there's a lot of thought and knowledge
> behind his reasoning. Hence if I were implementing exfat and
> Christoph was saying "throw it away and extend fs/fat"
> then that's what I'd be doing.
Again, I'm not ruling that out if that's the consensus direction. After all,
the goal is to merge a working driver - and for that, I need to produce
something that the file system maintainers will be willing to merge, which
means doing it in a way they want it...
Hopefully next week a few other people will weigh in with what they prefer as
far as approach goes. Only definite statement I've heard so far was
Christoph's...
> and we don't want more. Implementing exfat on top of fs/fat kills
> two birds with one stone - it modernises the fs/fat code base and
> brings new functionality that will have more developers interested
> in maintaining it over the long term.
Any recommendations on how to approach that? Clone the current fs/fat code
and develop on top of that, or create a branch of it and on occasion do the
merging needed to track further fs/fat development?
Mostly asking for workflow suggestions - what's known to work well for this
sort of situation, where we know we won't be merging until we have several
thousand lines of new code? And any "don't do <this> or you'll regret it
later" advice is also appreciated. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-08-31 10:25 ` Valdis Klētnieks
2019-08-31 14:24 ` Andy Shevchenko
2019-09-01 1:07 ` Dave Chinner
@ 2019-09-02 7:35 ` Christoph Hellwig
2019-09-02 15:25 ` Greg Kroah-Hartman
2 siblings, 1 reply; 20+ messages in thread
From: Christoph Hellwig @ 2019-09-02 7:35 UTC (permalink / raw)
To: Valdis Klētnieks
Cc: Christoph Hellwig, Greg Kroah-Hartman, Sasha Levin,
linux-fsdevel, linux-kernel
On Sat, Aug 31, 2019 at 06:25:21AM -0400, Valdis Klētnieks wrote:
> On Fri, 30 Aug 2019 23:46:16 -0700, Christoph Hellwig said:
>
> > Since when did Linux kernel submissions become "show me a better patch"
> > to reject something obviously bad?
>
> Well, do you even have a *suggestion* for a better idea? Other than "just rip
> it out"? Keeping in mind that:
The right approach in my opinion is to start submitting patches to fs/fat
to add exfat support. But more importantly it is to first coordinate
with other stakeholder most importantly the fs/fat/ maintainer and the
dosfstools maintainers as our local experts for fat-like file systems
instead of shooting from the hip.
> I think at that point, we can safely say that if it mounts a vfat filesystem,
> it's because the person building the kernel has gone out of their way to
> request that it do so.
Especially with boot time automounting it could happen. Never mind that
we do not add duplicate file system drivers (or drivers in general) to
the kernel.
> Now, if what you want is "Please make it so the fat16/fat32 code is in separate
> files that aren't built unless requested", that's in fact doable and a
> reasonable request, and one that both doesn't conflict with anything other
> directions we might want to go, and also prepares the code for more easy
> separation if it's decided we really do want an exfat-only module.
No. Assuming we even want the current codebase (which only you and
Greg seem to think so), that fat16/32 code simply has to go.
> And by the way, it seems like other filesystems rely on "others" to help out.
> Let's look at the non-merge commit for fs/ext4. And these are actual patches,
> not just reviewer comments....
>
> (For those who don't feel like scrolling - 77.6% of the non-merge ext4 commits
> are from a total of 463 somebodies other than Ted Ts'o)
>
> Even some guy named Christoph Hellwig gave Ted Ts'o a bunch of help.
That isn't the point. Everyone who submitted a file system had a clear
plan where they wanted to go. You just took someone elses out of tree
code, apparently didn't even try to understand it and are not able to
come up with what your plan for it is. And even after repeated
questions on what that plan is duck the question and instead attack the
people asking for it.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-09-01 23:13 ` Valdis Klētnieks
@ 2019-09-02 7:38 ` Christoph Hellwig
0 siblings, 0 replies; 20+ messages in thread
From: Christoph Hellwig @ 2019-09-02 7:38 UTC (permalink / raw)
To: Valdis Klētnieks
Cc: Dave Chinner, Christoph Hellwig, Greg Kroah-Hartman, Sasha Levin,
linux-fsdevel, linux-kernel
On Sun, Sep 01, 2019 at 07:13:54PM -0400, Valdis Klētnieks wrote:
> Any recommendations on how to approach that? Clone the current fs/fat code
> and develop on top of that, or create a branch of it and on occasion do the
> merging needed to track further fs/fat development?
>
> Mostly asking for workflow suggestions - what's known to work well for this
> sort of situation, where we know we won't be merging until we have several
> thousand lines of new code? And any "don't do <this> or you'll regret it
> later" advice is also appreciated. :)
Just try to hack it in in your local tree and see if it works at all.
Normally you should have a feeling of where this is heading at this
point and start iterating. One it looks somewhat presentable send it
out to the list and ask for comments.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-09-02 7:35 ` Christoph Hellwig
@ 2019-09-02 15:25 ` Greg Kroah-Hartman
2019-09-02 19:00 ` Valdis Klētnieks
0 siblings, 1 reply; 20+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-02 15:25 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Valdis Klētnieks, Sasha Levin, linux-fsdevel, linux-kernel
On Mon, Sep 02, 2019 at 12:35:25AM -0700, Christoph Hellwig wrote:
> On Sat, Aug 31, 2019 at 06:25:21AM -0400, Valdis Klētnieks wrote:
> > On Fri, 30 Aug 2019 23:46:16 -0700, Christoph Hellwig said:
> >
> > > Since when did Linux kernel submissions become "show me a better patch"
> > > to reject something obviously bad?
> >
> > Well, do you even have a *suggestion* for a better idea? Other than "just rip
> > it out"? Keeping in mind that:
>
> The right approach in my opinion is to start submitting patches to fs/fat
> to add exfat support. But more importantly it is to first coordinate
> with other stakeholder most importantly the fs/fat/ maintainer and the
> dosfstools maintainers as our local experts for fat-like file systems
> instead of shooting from the hip.
I dug up my old discussion with the current vfat maintainer and he said
something to the affect of, "leave the existing code alone, make a new
filesystem, I don't want anything to do with exfat".
And I don't blame them, vfat is fine as-is and stable and shouldn't be
touched for new things.
We can keep non-vfat filesystems from being mounted with the exfat
codebase, and make things simpler for everyone involved.
> > Now, if what you want is "Please make it so the fat16/fat32 code is in separate
> > files that aren't built unless requested", that's in fact doable and a
> > reasonable request, and one that both doesn't conflict with anything other
> > directions we might want to go, and also prepares the code for more easy
> > separation if it's decided we really do want an exfat-only module.
>
> No. Assuming we even want the current codebase (which only you and
> Greg seem to think so), that fat16/32 code simply has to go.
I don't think it should stay in there, let's drop it from the exfat
code.
As for the other issues discussed here in this thread:
- yes, putting a filesystem in staging is extra work overall, but for
projects that want to do that extra work, wonderful, do it here in a
common place for everyone to work on together.
- working on in a common place is what we need for exfat right now,
as there are 40+ different github forks and no one knows which one
is "correct" or most up to date. We needed to decide on "one" and
here it is, the in-tree one.
- for vfs developers who don't want to even look at the crud in
staging (remember, it's TAINT_CRAP if you load code from here),
don't. Just keep on your own normal development cycles and if you
break any staging code, it's fine, I will fix it up no complaints at
all.
- staging code is for crappy code to get fixed up. If it isn't
constantly updated, it will be dropped. Yes, there is code in there
that probably should be dropped now as I haven't done a sweep in a
few years, suggestions always welcome. There is also code that
needs to be moved out with just a bit more work needed (greybus,
comedi, speakup, etc.) Some of that is underway right now.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-09-02 15:25 ` Greg Kroah-Hartman
@ 2019-09-02 19:00 ` Valdis Klētnieks
2019-09-02 19:06 ` Greg Kroah-Hartman
0 siblings, 1 reply; 20+ messages in thread
From: Valdis Klētnieks @ 2019-09-02 19:00 UTC (permalink / raw)
To: Greg Kroah-Hartman, OGAWA Hirofumi
Cc: Christoph Hellwig, Sasha Levin, linux-fsdevel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 578 bytes --]
On Mon, 02 Sep 2019 17:25:24 +0200, Greg Kroah-Hartman said:
> I dug up my old discussion with the current vfat maintainer and he said
> something to the affect of, "leave the existing code alone, make a new
> filesystem, I don't want anything to do with exfat".
>
> And I don't blame them, vfat is fine as-is and stable and shouldn't be
> touched for new things.
>
> We can keep non-vfat filesystems from being mounted with the exfat
> codebase, and make things simpler for everyone involved.
Ogawa:
Is this still your position, that you want exfat to be a separate module?
[-- Attachment #2: Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-09-02 19:00 ` Valdis Klētnieks
@ 2019-09-02 19:06 ` Greg Kroah-Hartman
2019-09-08 10:50 ` OGAWA Hirofumi
0 siblings, 1 reply; 20+ messages in thread
From: Greg Kroah-Hartman @ 2019-09-02 19:06 UTC (permalink / raw)
To: Valdis Klētnieks
Cc: OGAWA Hirofumi, Christoph Hellwig, Sasha Levin, linux-fsdevel,
linux-kernel
On Mon, Sep 02, 2019 at 03:00:17PM -0400, Valdis Klētnieks wrote:
> On Mon, 02 Sep 2019 17:25:24 +0200, Greg Kroah-Hartman said:
>
> > I dug up my old discussion with the current vfat maintainer and he said
> > something to the affect of, "leave the existing code alone, make a new
> > filesystem, I don't want anything to do with exfat".
> >
> > And I don't blame them, vfat is fine as-is and stable and shouldn't be
> > touched for new things.
> >
> > We can keep non-vfat filesystems from being mounted with the exfat
> > codebase, and make things simpler for everyone involved.
>
> Ogawa:
>
> Is this still your position, that you want exfat to be a separate module?
Personally I agree that this should be separate at least for quite some
time to shake things out at the very least. But I'll defer to Ogawa if
he thinks things should be merged.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
2019-09-02 19:06 ` Greg Kroah-Hartman
@ 2019-09-08 10:50 ` OGAWA Hirofumi
0 siblings, 0 replies; 20+ messages in thread
From: OGAWA Hirofumi @ 2019-09-08 10:50 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Valdis Klētnieks, Christoph Hellwig, Sasha Levin,
linux-fsdevel, linux-kernel
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> On Mon, Sep 02, 2019 at 03:00:17PM -0400, Valdis Klētnieks wrote:
>> On Mon, 02 Sep 2019 17:25:24 +0200, Greg Kroah-Hartman said:
>>
>> > I dug up my old discussion with the current vfat maintainer and he said
>> > something to the affect of, "leave the existing code alone, make a new
>> > filesystem, I don't want anything to do with exfat".
>> >
>> > And I don't blame them, vfat is fine as-is and stable and shouldn't be
>> > touched for new things.
>> >
>> > We can keep non-vfat filesystems from being mounted with the exfat
>> > codebase, and make things simpler for everyone involved.
>>
>> Ogawa:
>>
>> Is this still your position, that you want exfat to be a separate module?
>
> Personally I agree that this should be separate at least for quite some
> time to shake things out at the very least. But I'll defer to Ogawa if
> he thinks things should be merged.
I'm not reading whole of this thread, so I can be pointless though. I
can't recall the discussion of exfat with you. My history about exfat
is,
write read-only exfat from on-disk data -> MS published patent to
their site or such -> stopped about exfat -> recently looks like MS
changed mind
Well, if you are going to developing actively, IMO it would be better to
drop historically bad decisions in fat driver (some stuff would be hard
to fix without user visible changes), and re-think from basic
implementation design.
And I can't recall the detail of exfat format though, IIRC, the common
code is not so big, but some stuff can be shared with fat (timestamp
stuff, fatent stuff, IIRC). So IMO it is better to be different driver
basically, however on other hand, it is better to share the code for
same on-disk format if possible.
Anyway, I don't have strong opinion about it.
Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2019-09-08 10:50 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-30 16:42 [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat Valdis Klētnieks
2019-08-30 16:45 ` Christoph Hellwig
2019-08-31 0:48 ` Valdis Klētnieks
2019-08-31 6:46 ` Christoph Hellwig
2019-08-31 10:25 ` Valdis Klētnieks
2019-08-31 14:24 ` Andy Shevchenko
2019-08-31 14:51 ` Valdis Klētnieks
2019-09-01 1:07 ` Dave Chinner
2019-09-01 1:37 ` Gao Xiang
2019-09-01 3:05 ` Al Viro
2019-09-01 3:26 ` Gao Xiang
2019-09-01 3:37 ` Valdis Klētnieks
2019-09-01 22:43 ` Dave Chinner
2019-09-01 23:13 ` Valdis Klētnieks
2019-09-02 7:38 ` Christoph Hellwig
2019-09-02 7:35 ` Christoph Hellwig
2019-09-02 15:25 ` Greg Kroah-Hartman
2019-09-02 19:00 ` Valdis Klētnieks
2019-09-02 19:06 ` Greg Kroah-Hartman
2019-09-08 10:50 ` OGAWA Hirofumi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).