Hi David, Al,
On 2018/9/6 7:25, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 29 Aug 2018 09:44:03 +1000 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
>>
>> On Tue, 28 Aug 2018 22:13:02 +0800 Chao Yu <yuchao0@xxxxxxxxxx> wrote:
>>>
>>> On 2018/8/28 21:05, Greg Kroah-Hartman wrote:
>>>> On Tue, Aug 28, 2018 at 04:56:43PM +0800, Chao Yu wrote:
>>>>>
>>>>> On 2018/8/28 14:28, Gao Xiang wrote:
>>>>>>
>>>>>> 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@xxxxxxxxxxxxx>
>>>>>>>> Cc: David Howells <dhowells@xxxxxxxxxx>
>>>>>>>> Reviewed-by: Chao Yu <yuchao0@xxxxxxxxxx>
>>>>>>>> Signed-off-by: Gao Xiang <gaoxiang25@xxxxxxxxxx>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> 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@xxxxxxxxxx/
>>>>>>>> https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxiang25@xxxxxxxxxx/
>>>>>>>
>>>>>>> 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@xxxxxxxxxxxxxxxx/
>>>>>>
>>>>>>> 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.
>>>>
>>>> Ok, you are right, I'll go apply this.
>>>>
>>>>>> 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...
>>>>
>>>> As the code is now part of the common tree that everyone works off of,
>>>> any filesystem changes that happen will normally cover erofs as well.
>>>> So this shouldn't be an issue anymore.
>>>
>>> Thanks very much for the help and explanation, we will keep an eye on those vfs
>>> changes. :)
>>
>> Unfortunately, those vfs changes are still in the vfs tree in
>> linux-next and cause a build failure in the erofs code. I have
>> disabled the build of erofs again for today.
>>
>> Dave, Al, it would be good if you could add a patch/revise the series
>> that adds the necessary erofs changes.
>
> I still have to disable erofs .....
>
Is there some plan to fix erofs in the new mount-api patchset?
Or should I send erofs patches based on the dhowells/mount-api branch? and could you please help review and merge them?
Thanks in advance.
Thanks,
Gao Xiang
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
