Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp603913ybm; Fri, 29 May 2020 07:52:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz/jmcz7WsUaZmOL/t0hAfjuFhmZ/CIElX4Kqw7XG942627kneyKqBcJZrg3x1zCZA/dR3w X-Received: by 2002:a17:906:39a:: with SMTP id b26mr8425806eja.204.1590763964792; Fri, 29 May 2020 07:52:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590763964; cv=none; d=google.com; s=arc-20160816; b=vUnqu2IVBjGKprQlXuXNAZz+K2nf48WT7JQkdv4oaQIFg92eaPQNcMcCtu5vxvoEHl Udt+O7y5q8+1E7YQHqXIeYXOMS3t7MY+IMvn/aWzCzbA1OLFYRN6kL6avLWKxwXmrdGe q2e+188/C9s0aEU6Z7oiL1a0L8sLmbopgYpqKl8/jIivyAO/QVshf8iKj8lwHMBBt3qM EIObhCLA2hVso0NqmVTusqgKO1DABVArILlH0hdakmoEZRJInfUlLDvWD/NsrM4xESLJ KnEBirwoWfHGkggBMINpT4nJuXW+WVaCUOJ6EiVn0ejqK/gEMxZ92ebqWsdM61V7cutT AlEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=9WlVsdWU/ye2osgRTOkw0sfktljZUBDt8IESFs68H3c=; b=JD5oBEnGhzvomcVq84+UyDXNtIPFlDHEt/xPGmMMwOSPxne9XbGvSGWdBSLpSHRxRx B2r4Oovph68NSD2B4qO49L+a1z3yU5pkD+oMJOIKtaYkWwiAmN3LhNOEJv6FC2pBebxY N2buAh3RW+N4SrXJPrkzj5O6Wxk4miyp5T7lc28q6qnfd0dPYSp0iPAmTdySiuYTKPxy L9iDZeOvFAVaqeoCWLn029CapdaIK20d0u/aPh6Z2m92JZkZhiC/Jjs4ftQAMo50/q/r VG4xiE3OxPOyM5h4t1w9cBrrgjaJJozKDifkQfoBCE6fYU69Zq+RnzE2pZek9pHxjkB2 2CtQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=W5qmBwXS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c2si5758905edm.499.2020.05.29.07.52.20; Fri, 29 May 2020 07:52:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=W5qmBwXS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727101AbgE2Oua (ORCPT + 99 others); Fri, 29 May 2020 10:50:30 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:48381 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726838AbgE2Ou3 (ORCPT ); Fri, 29 May 2020 10:50:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590763827; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9WlVsdWU/ye2osgRTOkw0sfktljZUBDt8IESFs68H3c=; b=W5qmBwXSd9YaylTVI88BcO6YWpg4tyyA0lzjfqIpPQRBAQGimTKaXa0RwtEDSEBhCrEWwn 3syP5KS7VaVsAend0zduu6A7SIYCfcE91bHiF0DcG4AeYMno4srveM/h2QKPL7owifE5g0 ajWIfjWt1hn2ySDEVitvH03i1ENxCW4= Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-499-NRa1JaLwNqa2cOCUUgv-0g-1; Fri, 29 May 2020 10:50:26 -0400 X-MC-Unique: NRa1JaLwNqa2cOCUUgv-0g-1 Received: by mail-pl1-f199.google.com with SMTP id d9so2160552pll.12 for ; Fri, 29 May 2020 07:50:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=9WlVsdWU/ye2osgRTOkw0sfktljZUBDt8IESFs68H3c=; b=YhsZkUDcWYuX9TzS/jVqYWeJh/kscyhNqmx+ogyBFxCEwP5yfwKcLGI8TO1G+OyaME Qf8O3nPwfNfb+JYd6vey1UJDGpxpab/JWTA/fijRa3OtbAVOQJrtBRe9y5WOOUwpeHvT UtuMhMd0SQpC1VSdj/X1q+69SoieWddzqKyqi5vqtXInbetOnkKnkSPpW4rOl0fonXD6 21yxQ7LqdRDYKnVqhIX54cfVjG+0bghDlNkF7HhlTQyjWP8QYYHeqC+l9bgMPAsAdm8E EvPGx0H/WzCYhpsF3rgf9o5ox0tg0PElyHCahHxOauep0n9Yng6kdEfgBDKVPD6ZwQwl iBZQ== X-Gm-Message-State: AOAM532t0K7EUMCJ6N+4l/mSoIX/OBTKRopaKHy3hC2eGSmNF+H+482A gqY50hFhkktXTmCjuJ4Kh1idLlZNrdXm5+F2gqFFCE3yhAz8Fqo4+mWmNWuxDgtkI7wJeY4GgI8 NKfoj9UDZLIs/sL75HUtAOh9K X-Received: by 2002:a63:348b:: with SMTP id b133mr8439237pga.319.1590763825022; Fri, 29 May 2020 07:50:25 -0700 (PDT) X-Received: by 2002:a63:348b:: with SMTP id b133mr8439219pga.319.1590763824766; Fri, 29 May 2020 07:50:24 -0700 (PDT) Received: from xiangao.remote.csb ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id r1sm7054983pgb.37.2020.05.29.07.50.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 May 2020 07:50:24 -0700 (PDT) Date: Fri, 29 May 2020 22:50:13 +0800 From: Gao Xiang To: Al Viro Cc: Stephen Rothwell , Gao Xiang , Linux Next Mailing List , Linux Kernel Mailing List , Chengguang Xu , Chao Yu Subject: Re: linux-next: manual merge of the vfs tree with the erofs tree Message-ID: <20200529145013.GA22698@xiangao.remote.csb> References: <20200529114501.3e2ecc14@canb.auug.org.au> <20200529015111.GA23230@ZenIV.linux.org.uk> <20200529034007.GA12648@xiangao.remote.csb> <20200529143613.GE23230@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200529143613.GE23230@ZenIV.linux.org.uk> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 29, 2020 at 03:36:13PM +0100, Al Viro wrote: > On Fri, May 29, 2020 at 11:40:07AM +0800, Gao Xiang wrote: > > > I'm fine with that, although I think it's mainly with vfs changes > > so could be better though with vfs tree. I will add this patch > > tomorrow anyway... Thanks for reminder! > > FWIW, my reasoning here is > * erofs tree exists and > * the patch is erofs-specific, affects nothing outside and > has no dependencies with anything currently done in VFS or in other > filesystems and > * it does have (trivial) conflicts with the stuff in > erofs tree > > So putting it into erofs tree would seem to be an obvious approach - > minimizes the amount of cross-tree dependencies and headache for > everyone involved... That is reasonable. btw, our initial thought was that relates to new mount apis and we weren't very confident if it really went the filesystem itself... > > I'm dropping it from #work.misc and #for-next now. I will push out for next cycle. Thanks for detailed explanation. Thanks, Gao Xiang >