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,URIBL_BLOCKED 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 E1C1AC282C8 for ; Mon, 28 Jan 2019 07:57:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BC55A21736 for ; Mon, 28 Jan 2019 07:57:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726746AbfA1H56 (ORCPT ); Mon, 28 Jan 2019 02:57:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46540 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726627AbfA1H56 (ORCPT ); Mon, 28 Jan 2019 02:57:58 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4696586673; Mon, 28 Jan 2019 07:57:57 +0000 (UTC) Received: from localhost (ovpn-200-19.brq.redhat.com [10.40.200.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1FB8460BE0; Mon, 28 Jan 2019 07:57:53 +0000 (UTC) Date: Mon, 28 Jan 2019 08:57:48 +0100 From: Stefano Brivio To: Roopa Prabhu Cc: Nikolay Aleksandrov , David Ahern , Phil Sutter , Eric Garver , Tomas Dolezal , Stephen Hemminger , Lennert Buytenhek , netdev Subject: Re: [PATCH iproute2-next] Introduce ip-brctl shell script Message-ID: <20190128085748.57cbeff5@redhat.com> In-Reply-To: References: <800cb3d3-c749-3f36-83ea-0375e67fbd33@cumulusnetworks.com> <20190125110543.35693aee@elisabeth> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 28 Jan 2019 07:57:57 +0000 (UTC) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, 27 Jan 2019 21:08:13 -0800 Roopa Prabhu wrote: > On Fri, Jan 25, 2019 at 2:05 AM Stefano Brivio wrote: > > > > Hi Roopa, > > > > On Wed, 23 Jan 2019 08:33:27 -0800 > > Roopa Prabhu wrote: > > > > > On Wed, Jan 23, 2019 at 7:09 AM Nikolay Aleksandrov > > > wrote: > > > > > > > Hi, > > > > IMO the effort should be towards improving iproute2 to be > > > > easier to use and more intuitive. We should be pushing people to > > > > use the new tools instead of trying to find workarounds to keep the > > > > old tools alive. I do like to idea of deprecating bridge-utils, but > > > > I think it should be done via improving ip/bridge enough to be > > > > pleasant to use. We will have to maintain this compatibility layer > > > > forever if it gets accepted and we'll never get rid of brctl this > > > > way. > > > > > > +1, we should move people away from brtcl. there is enough confusion > > > among users looking at bridge attributes., > > > > > > ip -d link show > > > bridge -d link show > > > brctl > > > > Why is this confusing? One can simply pick the most appropriate tool. > > > > > Adding a 4th one to the list is not going to ease the confusion. > > > > Why do you say I'm adding a fourth (I guess) tool? I'm replacing the > > third one. > > I know. But the first two commands were supposed to replace the third > one already. > and they should be. They can't replace brctl not because they are badly designed or unusable, but simply because they are different tools with different purposes (see also my comments to Nikolay). > So, I think its better to fix the first two instead of introducing > another one. This is really not the same thing: I'm not introducing a new tool, I'm effectively replacing a 1794-LoC, non-trivial, ioctl-based implementation with a trivial, 572-lines shell script, with half the binary size. I'm not doing this on bridge-utils directly because that would imply the need to still maintain a different tool. For all practical maintenance purposes, I'm actually getting rid of a separate tool, which is my only goal here. I'd rather say we go from 3 tools to slightly more than 2. > > > We should try to make the 'ip -d link show and bridge -d link show' > > > outputs better. Any suggestions there from people will be useful. > > > > To be honest, I don't see any problem with them -- they just do > > different things. > > Can we extend 'bridge' tool with extra options to provide a summary > view of all bridges like brctl ? We could, and I initially thought of that approach instead, but that has a number of fundamental downsides: - we can't provide a brctl-compatible syntax, unless we want to substantially rewrite the 'bridge' interface, and I think it's a bad idea to break 'bridge' syntax for users, while we won't be able to replace brctl if we don't provide a similar syntax, history showed - the fdb implementation has a long-dated comment by Stephen in its header, * TODO: merge/replace this with ip neighbour and this is actually the only part of 'bridge' I'm using in ip-brctl. Code is conceptually duplicated there, and I think we should actually get rid of that -- but then 'bridge' wouldn't even give information about the FDB, one would need to use ip neighbour instead. - 'bridge' doesn't implement settings for basic bridge features (say, STP), which are convenient for users, especially if they are used to brctl. To get that, even at an interface/syntax level, we would need to duplicate some parts of ip-link, which looks like a bad idea per se. > Its supposed to be the netlink based tool for all bridging and hence > could be a good replacement for all brctl users. I still think the best replacement for users is the one that changes absolutely nothing, and if that's easily achievable, I'd rather go for it. -- Stefano