linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
Cc: Christoph Hellwig <hch@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sasha Levin <alexander.levin@microsoft.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
Date: Fri, 30 Aug 2019 23:46:16 -0700	[thread overview]
Message-ID: <20190831064616.GA13286@infradead.org> (raw)
In-Reply-To: <267691.1567212516@turing-police>

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.

  reply	other threads:[~2019-08-31  6:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20190831064616.GA13286@infradead.org \
    --to=hch@infradead.org \
    --cc=alexander.levin@microsoft.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=valdis.kletnieks@vt.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).