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.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 98B5BC43381 for ; Thu, 28 Feb 2019 19:56:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 114A0218AE for ; Thu, 28 Feb 2019 19:56:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=wp.pl header.i=@wp.pl header.b="R/PGIvnK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388056AbfB1T4z (ORCPT ); Thu, 28 Feb 2019 14:56:55 -0500 Received: from mx3.wp.pl ([212.77.101.10]:9172 "EHLO mx3.wp.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726231AbfB1T4y (ORCPT ); Thu, 28 Feb 2019 14:56:54 -0500 Received: (wp-smtpd smtp.wp.pl 3040 invoked from network); 28 Feb 2019 20:56:50 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1551383811; bh=3S9JDez21O2U+S968sfw8L0TLt5mKqVB1JVJHD1WWp8=; h=From:To:Cc:Subject; b=R/PGIvnK17NSyhIbu6IqZMki6t28cH7wbwOLxYQZXJ58mHG/WuaLvS3JWQAJMgEUh 7nOH8uP2ImFbCCpMYmiElGgL8nfS3BhRwTBy/z+qBrccy2/qKQmAq61j6jl8S6bn8y O3caJqcBmIL7TEIwupax2O9zcBwTIWyZVAvExIJ4= Received: from 014.152-60-66-biz-static.surewest.net (HELO cakuba.netronome.com) (kubakici@wp.pl@[66.60.152.14]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 28 Feb 2019 20:56:50 +0100 Date: Thu, 28 Feb 2019 11:56:41 -0800 From: Jakub Kicinski To: "Michael S. Tsirkin" Cc: si-wei liu , "Samudrala, Sridhar" , Siwei Liu , Jiri Pirko , Stephen Hemminger , David Miller , Netdev , virtualization@lists.linux-foundation.org, "Brandeburg, Jesse" , Alexander Duyck , 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: <20190228115641.7afe6f09@cakuba.netronome.com> In-Reply-To: <20190228143511-mutt-send-email-mst@kernel.org> References: <20190227173710-mutt-send-email-mst@kernel.org> <20190227184601-mutt-send-email-mst@kernel.org> <20190227193923-mutt-send-email-mst@kernel.org> <20190227165205.307ed83c@cakuba.netronome.com> <20190227201857-mutt-send-email-mst@kernel.org> <20190227175218.736e13b6@cakuba.netronome.com> <20190227233812-mutt-send-email-mst@kernel.org> <20190228101356.39ac70aa@cakuba.netronome.com> <20190228143511-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-WP-MailID: 00d86db7eb2c6e6fdd9cbb1d3125429d X-WP-AV: skaner antywirusowy Poczty Wirtualnej Polski X-WP-SPAM: NO 0000000 [ARPU] Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, 28 Feb 2019 14:36:56 -0500, Michael S. Tsirkin wrote: > > It is a bit of a the chicken or the egg situation ;) But users can > > just blacklist, too. Anyway, I think this is far better than module > > parameters > > Sorry I'm a bit confused. What is better than what? I mean that blacklist net_failover or module param to disable net_failover and handle in user space are better than trying to solve the renaming at kernel level (either by adding module params that make the kernel rename devices or letting user space change names of running devices if they are slaves). > > for twiddling kernel-based interface naming policy.. :S > > I see your point. But my point is slave names don't really matter, only > master name matters. So I am not sure there's any policy worth talking > about here. Oh yes, I don't disagree with you, but others seems to want to rename the auto-bonded lower devices. Which can be done trivially if it was a daemon in user space instantiating the auto-bond. We are just providing a basic version of auto-bonding in the kernel. If there are extra requirements on policy, or naming - the whole thing is better solved in user space.