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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 6F035C00319 for ; Thu, 28 Feb 2019 00:38:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3F2FA214D8 for ; Thu, 28 Feb 2019 00:38:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730587AbfB1Aik (ORCPT ); Wed, 27 Feb 2019 19:38:40 -0500 Received: from mail-qt1-f193.google.com ([209.85.160.193]:35112 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730139AbfB1Aii (ORCPT ); Wed, 27 Feb 2019 19:38:38 -0500 Received: by mail-qt1-f193.google.com with SMTP id p48so21629776qtk.2 for ; Wed, 27 Feb 2019 16:38:38 -0800 (PST) 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; bh=or6HCYlJHIqGblcXm1PmPe833eGYnLSm0P+tsGTy4Jo=; b=hx5wod/fkmCSlRPQES6E7jHAGg5K/BeyHCSkbBY4QnO3xgGttJSVTLqMr5Y+qXBIAr vB82jgcsCqBZpMptCcvFvTv4ykg8FCBoiFexWSfvaT1nPRBlbgsQR4UuzD4M8K6B9Hr0 3keUtZah+UHPmLtSJHwhtfEdo/v/Y3u2uEafngOeUvD0YTNcbJ5yFRfBJlviRbVkUtzW ZvBz5PDvhzNT+C0O8pNnlHsVlxyZKM9rUAyJmgw1MA0SnTBTp0MePCS0HGWusnyGo87S c4hdCi7aYi9GpStrOwINEU6fHHyn1X5bXqsuOLdquY7yu8FYmdCh/XV6nu92Fs9fSrFY vLlw== X-Gm-Message-State: APjAAAXq1yoAJN1nkQcYdSVqVD43XCxwa2gP7UKbSYEv+AaD/H6QlS0y fAJ+X4OchjCWpYepJfTMwV2LdcSRcw082g== X-Google-Smtp-Source: AHgI3IY0aQbpoQN0POdEn3+AHeKhfHVexH8Q5Nl2n4Yp7UErxdbvDLXRXOPKgfY7Yxpls6yqrhQYUg== X-Received: by 2002:aed:2269:: with SMTP id o38mr4184274qtc.222.1551314317717; Wed, 27 Feb 2019 16:38:37 -0800 (PST) Received: from redhat.com (pool-173-76-246-42.bstnma.fios.verizon.net. [173.76.246.42]) by smtp.gmail.com with ESMTPSA id 81sm9686083qkg.75.2019.02.27.16.38.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 27 Feb 2019 16:38:36 -0800 (PST) Date: Wed, 27 Feb 2019 19:38:34 -0500 From: "Michael S. Tsirkin" To: Stephen Hemminger Cc: si-wei liu , "Samudrala, Sridhar" , Siwei Liu , Jiri Pirko , David Miller , Netdev , virtualization@lists.linux-foundation.org, virtio-dev , "Brandeburg, Jesse" , Alexander Duyck , Jakub Kicinski , Jason Wang , liran.alon@oracle.com Subject: Re: [virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH net-next v6 4/4] netvsc: refactor notifier/event handling code to use the bypass framework) Message-ID: <20190227193330-mutt-send-email-mst@kernel.org> References: <91d4cbb1-be7a-b53c-6b2a-99bef07e7c53@intel.com> <20190222100753-mutt-send-email-mst@kernel.org> <20190225210529-mutt-send-email-mst@kernel.org> <20190227173710-mutt-send-email-mst@kernel.org> <20190227184601-mutt-send-email-mst@kernel.org> <20190227160342.788dc2b4@shemminger-XPS-13-9360> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190227160342.788dc2b4@shemminger-XPS-13-9360> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Feb 27, 2019 at 04:03:42PM -0800, Stephen Hemminger wrote: > > With this approach kernel will deny attempts by userspace to rename > > slaves. Slaves will always be named XXXnsby and XXnpry. Master renames > > will rename both slaves. > > > > It seems pretty solid to me, the only issue is that in theory userspace > > can use a name like XXXnsby for something else. But this seems unlikely. > > Similar schemes (with kernel providing naming) were also previously rejected > upstream. Links? I'm inclined to try and see what happens. > It has been a consistent theme that the kernel should not be in > the renaming business. In this case it's not in renaming business per se. The only reason we even have the original name is due to the ways internal APIs work. You can look at it as simply having slaves names being part of master. > It will certainly break userspace. That's a strong claim. What is it based on? It so happens that userspace renaming slaves is already broken on virtio. So we can fix it any way we like :) And yes it won't help netvsc because netvsc wants compatibility with old scripts but then netvsc uses a 2 device model anyway. -- MST