[PATCH] Revert "staging: erofs: disable compiling temporarile"

[Chao Yu]

Hi Greg,

On 2018/8/28 14:28, Gao Xiang wrote:
> Hi Greg,
> 
> On 2018/8/28 13:44, Greg Kroah-Hartman wrote:
>> On Tue, Aug 28, 2018 at 11:39:48AM +0800, Gao Xiang wrote:
>>> This reverts commit 156c3df8d4db4e693c062978186f44079413d74d.
>>>
>>> Since XArray and the new mount apis aren't merged in 4.19-rc1
>>> merge window, the BROKEN mark can be reverted directly without
>>> any problems.
>>>
>>> Fixes: 156c3df8d4db ("staging: erofs: disable compiling temporarile")
>>> Cc: Matthew Wilcox <willy at infradead.org>
>>> Cc: David Howells <dhowells at redhat.com>
>>> Reviewed-by: Chao Yu <yuchao0 at huawei.com>
>>> Signed-off-by: Gao Xiang <gaoxiang25 at huawei.com>
>>> ---
>>>
>>> Hi Greg,
>>>
>>>  Could you please apply this patch to enable EROFS from 4.19-rc2, thanks...
>>>
>>>  p.s. We would like to provide a more stable EROFS when linux-4.19 is out,
>>>       and there are also two patchsets (the one is already sent out by Chao
>>>       and me, the other is previewing in linux-erofs mailing list and it will
>>>       be sent out after gathering enough testdata and feedback from community
>>>       and carefully reviewed), could you also please consider applying these
>>>       two patchsets in the later 4.19-rc (both >2, or the first patchset
>>>       could be in rc2 in advance) if it is convenient to do so, or the next
>>>       4.20 is also ok...
>>>
>>>  LINK: https://lore.kernel.org/lkml/20180821144937.20555-1-chao@kernel.org/
>>>        https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxiang25@huawei.com/
>>
>> I applied those patch sets to my -next branch already, right?  So those
> 
> Yes, Thank you for applying those patches. :)
> 
>> would be going into 4.20-rc1, it is time now for "bugfixes only" for
>> 4.19-final.
>>
>> So perhaps we should just leave it as "BROKEN" for now for 4.19 and add
>> this to my tree now and let people work on it for the next few months in

I'm worry about that once we plan to reenable erofs in next x.xx-rc1, in the
merge window, if there are any other features change common api or structure in
vfs/mm/block, but related patch didn't cover erofs, that would make conflict
with erofs.

So if that happens, we can just reminder them to cover erofs? or we should
handle this by just delay removing 'BROKEN' state?

Thanks,

>> linux-next so that 4.20 has a solid base to start with?
>>
> 
> EROFS is be marked as "BROKEN" just because of conflict with
> XArray and the new mount apis, as Stephen Rothwell suggested in
> 
> https://lore.kernel.org/lkml/20180802010705.24a72730@canb.auug.org.au/
> 
>> It might be easiest for Greg to add the disabling CONFIG_EROFS_FS patch
>> to the staging tree itself for his first pull request during the merge
>> window and then send a second pull request (after the vfs and maybe the
>> Xarray stuff has been merged by Linus) with these patches followed by a
>> revert of the disabling patch.
> 
> But these two features was still discussing in the mailing list even at the
> last time of 4.19-rc1 merge window. I cannot decide whether they were eventually
> get merged in 4.19 or not. But it seems that it is regretful that linux-4.19
> is out without XArray and the new mount apis.
> 
> Therefore, I think EROFS should work for linux-4.19 without any modification
> if just revert the BROKEN mark.
> 
> EROFS works fine with the 4.19-rc1 code except that it has some __GFP_NOFAIL
> and BUG_ONs on error handling paths and very rarely race between memory
> reclaiming and decompression... :( I personally think it is complete enough
> for people to test since it is an independent and staging filesystem driver (no
> other influence...) Anyway, removing EROFS BROKEN mark at 4.20 is also ok of course...
> 
> On the other head, if XArray and the new mount apis is still pending for 4.20,
> should EROFS uses the same policy as Stephen suggested? I have no idea how to do next...
> 
> 
> I would like to hear your and Chao's suggestions....Thanks in advance...
> 
> Thanks,
> Gao Xiang
> 
>> thanks,
>>
>> greg k-h
>>
> 
> .
>