Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp991906ybe; Thu, 19 Sep 2019 07:05:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqxNIOf8kHZwzmhSGB9Le7odwONef4HBlrrH7xIothzNVFgS9aWG8bfq3/NIwPW+x/jGnwE3 X-Received: by 2002:a50:8d5e:: with SMTP id t30mr16381050edt.112.1568901959267; Thu, 19 Sep 2019 07:05:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568901959; cv=none; d=google.com; s=arc-20160816; b=KcF4ZfJGbdJpyJmSQ9WeYkx39ngiCJlPfE+rY6UI4I8laI1xro+nF2gBxrg+OT4Xf5 DCYZh5x5UIfoK/5iteyUAaIugm7l5PXKLHpN/vpPivI25AGkek3sAHspSiMneVMLGzIr Be+aMeTSqRdqW5ziy4rowKctle7Tq4DMIluXPM5ITzicoifOzLW07/DCj8CH3HIzkeQR lnO85zig45rs/NaTw9itmcG7ImM3tb4pIWUbasXlLjDwv3s4NJdC7aAErb9OKWWyBqvO rnA4zqins+tC6GOX4+F9dc3xihDIlzchcVJTeF1O2pEeZNNO797BJWe9t2zMrAAXN+Y2 479Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=5/2Z+xK26B0Qa9nBtssF8FRk9MDYmDZ7v204MIYrXPQ=; b=Gk7x1l8W58HwxY3+M+7pFTX9UHIQGXofI7XVJg8Z6sB9XbI9zCslJ8f++02HorVxZn 38e8u7f1S6BOMsfqi1Y+bf3pM7RDlSwcKyypVfqczlf3KBWHc26fgalieFRD36XyIJ1I 87y04JZbO+KwLfTpclddM/hRvgite888pp/qmu9V7NLLa62DODZlBRtuV7lBWksAqFmi 49VU+8eYBfdjhjDKK7X6KfvZtBGZnDrhh6SlstzDt5Rig+UZ53nhDSOvWXCBrcqe4/4C 3BvY2NMJ1pQ7NYfO67toV8dTfrYPJv/yIWpl3uV4umDyPbF/ULiJfmSvyMbpR+snOqmn yr2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DLsWOHJy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b9si5495238edj.0.2019.09.19.07.05.35; Thu, 19 Sep 2019 07:05:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DLsWOHJy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732431AbfISODb (ORCPT + 99 others); Thu, 19 Sep 2019 10:03:31 -0400 Received: from mail-io1-f65.google.com ([209.85.166.65]:38252 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732143AbfISODb (ORCPT ); Thu, 19 Sep 2019 10:03:31 -0400 Received: by mail-io1-f65.google.com with SMTP id k5so7965272iol.5; Thu, 19 Sep 2019 07:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5/2Z+xK26B0Qa9nBtssF8FRk9MDYmDZ7v204MIYrXPQ=; b=DLsWOHJytMjXzqdooDAScGRrLwolZBO1OrSvUyszMDhy2r9hjOgN48Q86vlfMu1nSJ vUPEsxhOFj3/m8893jlHMEw4TQFJzkJET1FO9NTZ8cnCgGhDj+JBUf4RzoeLPXHWdbrz DXAgqZ9ijGaS4N0tckhsEbH9W3jtcRQq5rnCJ1NooVNIYpL70KoObUOfYRPHdQYhjsGQ 9ZASgQf6TGzeJITRB23Z2CuU9GtnVJCT1rm9N0YP4SOKKSGGrutz85sueZsV7SUB1ZaY //s1dQOZs07d2l55y9pa+biNMptcHOQDBvNZyD33Zum8+ESKRq609Ux8EaTE5ZVJq9Rt 7CGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5/2Z+xK26B0Qa9nBtssF8FRk9MDYmDZ7v204MIYrXPQ=; b=D3P62ocWCT77CcNThJLSnPNI9dP68AKCVE+hzBTa6QeDJSWuJFCpJYgAsK5ZRM0T4a nrpV3rIWjZR3vvFolynFumrFerfCLru2QZab2QTJ3eGggmeHlMHPtUSG/Axtg0HWQ3nY UHh3hLaR5giTBgdzCN8ouG+7MUCmFNNPrw+Zk0zzSmWzPdKbUdOER6Lh4tGxy6wEOOwF efNph1CFJlRE5uJzUVQphE1QhYPmTlQhpX4MHBR9RGhCDDPvqqPkxL2zdhwO8togZD9w ecPXUksMBar2G6pXBBmBQqI4/hrmWH5fxaQhg1AetOKettxkgOfGAMqMA5BtczJ7llY4 q4aQ== X-Gm-Message-State: APjAAAV8uMX2InoZ/nJBJAGgDhY3M4bGqni4ARH/Ki5gtczDdAgZE6MS A2XNqruqy77N+jwXfvOx+6cGoQf89tcET9H1IJ4= X-Received: by 2002:a5d:9f4e:: with SMTP id u14mr12333009iot.106.1568901810170; Thu, 19 Sep 2019 07:03:30 -0700 (PDT) MIME-Version: 1.0 References: <28368.1568875207@warthog.procyon.org.uk> <16147.1568632167@warthog.procyon.org.uk> <16257.1568886562@warthog.procyon.org.uk> <20190919131537.GA15392@bombadil.infradead.org> In-Reply-To: <20190919131537.GA15392@bombadil.infradead.org> From: Ilya Dryomov Date: Thu, 19 Sep 2019 16:03:20 +0200 Message-ID: Subject: Re: [GIT PULL afs: Development for 5.4 To: Matthew Wilcox Cc: David Howells , Linus Torvalds , YueHaibing , Marc Dionne , linux-afs@lists.infradead.org, linux-fsdevel , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 19, 2019 at 3:55 PM Matthew Wilcox wrote: > > On Thu, Sep 19, 2019 at 10:49:22AM +0100, David Howells wrote: > > David Howells wrote: > > > > > > However, I was close to unpulling it again. It has a merge commit with > > > > this merge message: > > > > > > > > Merge remote-tracking branch 'net/master' into afs-next > > > > > > > > and that simply is not acceptable. > > > > > > Apologies - I meant to rebase that away. There was a bug fix to rxrpc in > > > net/master that didn't get pulled into your tree until Saturday. > > > > Actually, waiting for all outstanding fixes to get merged and then rebasing > > might not be the right thing here. The problem is that there are fixes in > > both trees: afs fixes go directly into yours whereas rxrpc fixes go via > > networking and I would prefer to base my patches on both of them for testing > > purposes. What's the preferred method for dealing with that? Base on a merge > > of the lastest of those fixes in each tree? > > Why is it organised this way? I mean, yes, technically, rxrpc is a > generic layer-6 protocol that any blah blah blah, but in practice no > other user has come up in the last 37 years, so why bother pretending > one is going to? Just git mv net/rxrpc fs/afs/ and merge everything > through your tree. > > I feel similarly about net/9p, net/sunrpc and net/ceph. Every filesystem > comes with its own presentation layer; nobody reuses an existing one. > Just stop pretending they're separate components. net/ceph is also being used by drivers/block/rbd.c. net/ceph was split out of fs/ceph when rbd was introduced. We continued to manage them in a single ceph-client.git tree though. Thanks, Ilya