Re: Merging virtualbox shared-folder VFS driver through drivers/staging?

From: Gao Xiang <hsiangkao@aol.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hans de Goede <hdegoede@redhat.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	David Howells <dhowells@redhat.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: Merging virtualbox shared-folder VFS driver through drivers/staging?
Date: Mon, 12 Aug 2019 21:44:05 +0800	[thread overview]
Message-ID: <20190812134358.GA357@hsiangkao-HP-ZHAN-66-Pro-G1> (raw)
In-Reply-To: <20190812112247.GA21901@infradead.org>

On Mon, Aug 12, 2019 at 04:22:47AM -0700, Christoph Hellwig wrote:
> On Sun, Aug 11, 2019 at 09:50:42AM +0200, Greg Kroah-Hartman wrote:
> > Lustre was a mistake.  erofs is better in that there are active
> > developers working to get it out of staging.  We would also need that
> > here for this to be successful.
> 
> I think erofs could have been handled much easier with a bunch of
> iterations of normal submissions.  Bet yes, the biggest problem was
> lustre.

(I am trying...to add some word on this...)

As a new opensource file system, an unavoidable thing is trying to get
people opinions on this... It could be better to prove that's an interesting /
useful stuff for community so that we can do more actively with fun...
(Hopefully we got some attentions and no silence at first... thanks to
 Richard Weinberger, Pavel Machek, Joey Pabalinas... [1] p.s. I have no
 idea whether Richard still has some interest in it... but EROFS is
 ready now...)

At first, I submitted EROFS to linuxfs mailing list at the very early
stage, although the on-disk format is almost fixed, but I have to admit
that there were still stuffes needing to be done (Note that I updated
LZ4 (lib/lz4) later as well [2].)

we weren't quite sure that such an unclean/incomplete stuff was quite
good for better review at that time, and it was also lack of implementation
of some core runtime concepts such as decompression inplace (which was
only in my mind without real code) But we think this direction is
practical and we want to do iterations by time.

Also, we noticed there are many new stuffs such as fscontext, XArray,
multi-page bvec, which were introduced by time, we hope to keep up
with the mainline kernel...

Staging seems to be such a place for an incomplete but workable stuff
after I noticed what zram did before, therefore I took a try and
thanks Greg as well...

Thanks to merging into staging, many checkpatch/styling/functional
issues have been fixed by contributers... we can also have chance
to test in linux-next for many linux versions... and it's much
easier for us to do latest EROFS backport to 4.19LTS for our products...

On the other hand, since I have a paid job for a commerical company,
I need to apply EROFS unpainfully to our products. And I got many
useful running logs from our internal beta users, which helps us
make EROFS stable... Nowadays, almost all on-service HUAWEI mobile
phones on the market have been integrated with EROFS...

Now EROFS is ready for review, and the main code of EROFS is about
7KLOC... Sadly, it still haven't gotten some explicit external
ACKs till now... we don't know how we should do next to make a
difference... perhaps I thought it is relatively long thus I spilted
into 24 individual patches...

We really hope that it can be merged into fs/ in 5.4 so that we
can improve it even further and gain more users...

Thanks,
Gao Xiang

[1] https://lore.kernel.org/lkml/1670077.cnVahIradn@blindfold/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/lib/lz4