From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B26A4C11F66 for ; Tue, 13 Jul 2021 20:40:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9B0E9600D4 for ; Tue, 13 Jul 2021 20:40:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235353AbhGMUmt (ORCPT ); Tue, 13 Jul 2021 16:42:49 -0400 Received: from zeniv-ca.linux.org.uk ([142.44.231.140]:33282 "EHLO zeniv-ca.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235300AbhGMUms (ORCPT ); Tue, 13 Jul 2021 16:42:48 -0400 Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1m3OrF-000NQg-Hw; Tue, 13 Jul 2021 20:18:21 +0000 Date: Tue, 13 Jul 2021 20:18:21 +0000 From: Al Viro To: Linus Torvalds Cc: Hans de Goede , linux-fsdevel , LKML Subject: Re: [GIT PULL] vboxsf fixes for 5.14-1 Message-ID: References: <30c7ec73-4ad5-3c4e-4745-061eb22f2c8a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 13, 2021 at 08:14:04PM +0000, Al Viro wrote: > On Tue, Jul 13, 2021 at 12:15:13PM -0700, Linus Torvalds wrote: > > On Tue, Jul 13, 2021 at 3:45 AM Hans de Goede wrote: > > > > > > Linus, sorry for sending this directly through you, instead of going > > > through some other tree, but trying to get this upstream through the > > > linux-fsdevel list / patch-review simply is not working. > > > > Well, the filesystem maintainer sending their patches to me as a pull > > request is actually the norm rather than the exception when it comes > > to filesystems. > > > > It's a bit different for drivers, but that's because while we have > > multiple filesystems, we have multiple _thousand_ drivers, so on the > > driver side I really don't want individual driver maintainers to all > > send me their individual pull requests - that just wouldn't scale. > > > > So for individual drivers, we have subsystem maintainers, but for > > individual filesystems we generally don't. > > > > (When something then touches the *common* vfs code, that's a different > > thing - but something like this vboxsf thing this pull request looks > > normal to me). > > To elaborate a bit - there's one case when I want it to go through > vfs.git, and that's when there's an interference between something > going on in vfs.git and the work done in filesystem. Example: if there's a series changing calling conventions for some method brewing in vfs.git and changes to filesystem's instance of that method in the filesystem tree. Then I'd rather it coordinated before either gets merged. It might be an invariant branch in either tree pulled by both, it might be a straight pull into vfs.git and sorting the things out there - depends upon the situation.