public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	devel@linuxdriverproject.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] Staging/IIO driver patches for 5.4-rc1
Date: Wed, 18 Sep 2019 20:50:10 +0200	[thread overview]
Message-ID: <20190918185010.GA1933470@kroah.com> (raw)
In-Reply-To: <20190918182412.GA9924@infradead.org>

On Wed, Sep 18, 2019 at 11:24:12AM -0700, Christoph Hellwig wrote:
> Just as a note of record:  I don't think either file system move
> is a good idea.  erofs still needs a lot of work, especially in
> interacting with the mm code like abusing page->mapping.

At least it is special-purpose "read only" filesystem currently shipping
on a few million phones, so the fall-out isn't a big deal :)

Also, the erofs developers have been asking for reviews for a very long
time and only now got them.  Which goes back to the issue of vfs reviews
we all discussed last week (see below).

> exfat is just a random old code drop from Samsung hastily picked up,
> and also duplicating the fat16/32 functionality, and without
> consultation of the developes of that who are trying to work through
> their process of contributing the uptodate and official version of it.

Those developers are still yet to be found, we only got a "drop" of the
samsung code _after_ this code was merged, from non-samsung people.  No
samsung developers have said they would actually help with any of this
work, and when asked what differed from the in-tree stuff, I got a list,
but no specifics.  I'll be working through that list over the next month
to resolve those issues.

Also the fat16/32 code is disabled, so that shouldn't be a problem for
anyone.

Again, this is a special-purpose filesystem that will be under heavy
development for a while.  There was no common out-of-tree place that
everyone could actually work on this, just inumerable forks on github,
my own included.  Now we have that common place for this all to be
worked on, and also there is a very good legal benefit for this to be
in-tree, which always is a nice win.

To get back to the meta-problem here, we need a common "vfs/filesystem"
tree somewhere with reviewers.  I'm glad to set up the tree and handle
patches, but I am not a vfs expert by any means (I only understand the
virtual half, not the backing half), so I can't be the only one to do
reviews.  Do you know of anyone that we can drag in as reviewers to help
make it easier for new filesystems to get reviews as well as existing
ones to have their patches collected and forwarded on to Linus at the
proper times?

thanks,

greg k-h

  reply	other threads:[~2019-09-18 18:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-18 11:47 [GIT PULL] Staging/IIO driver patches for 5.4-rc1 Greg KH
2019-09-18 18:20 ` pr-tracker-bot
2019-09-18 18:24 ` Christoph Hellwig
2019-09-18 18:50   ` Greg KH [this message]
2019-09-18 20:47     ` Christoph Hellwig
2019-09-18 21:11   ` Gao Xiang
2019-09-18 22:44     ` Gao Xiang

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=20190918185010.GA1933470@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=devel@linuxdriverproject.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@linux-foundation.org \
    /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