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 C429CC282C0 for ; Fri, 25 Jan 2019 10:04:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9C67B218A2 for ; Fri, 25 Jan 2019 10:04:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729135AbfAYKEs (ORCPT ); Fri, 25 Jan 2019 05:04:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34128 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728238AbfAYKEs (ORCPT ); Fri, 25 Jan 2019 05:04:48 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D3C637BDB6; Fri, 25 Jan 2019 10:04:47 +0000 (UTC) Received: from elisabeth (ovpn-200-35.brq.redhat.com [10.40.200.35]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D869E608C3; Fri, 25 Jan 2019 10:04:43 +0000 (UTC) Date: Fri, 25 Jan 2019 11:04:37 +0100 From: Stefano Brivio To: Nikolay Aleksandrov Cc: David Ahern , Phil Sutter , Eric Garver , Tomas Dolezal , Stephen Hemminger , Lennert Buytenhek , netdev@vger.kernel.org Subject: Re: [PATCH iproute2-next] Introduce ip-brctl shell script Message-ID: <20190125110437.0f362a20@elisabeth> In-Reply-To: <800cb3d3-c749-3f36-83ea-0375e67fbd33@cumulusnetworks.com> References: <800cb3d3-c749-3f36-83ea-0375e67fbd33@cumulusnetworks.com> 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.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 25 Jan 2019 10:04:48 +0000 (UTC) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi Nik, On Wed, 23 Jan 2019 17:09:42 +0200 Nikolay Aleksandrov wrote: > 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. Indeed, it's not my intent here to push anybody to do anything. However, if you think there's some value in familiarising users with ip-link, we could, very easily with this script, print (perhaps on standard error?) the equivalent ip-link commands for any brctl command issued by the user. It's a couple of lines on top of this patch, because I'm already doing exactly that -- calculating equivalent ip-link commands. Something like: # brctl stp br0 on You might want to: "ip link set br0 type bridge stp_state 1" What do you think? > 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. My observation is that brctl is simply a different tool, not as generic as ip-link, and hence I find it acceptable and understandable that users (just as I do, I'll admit) feel more comfortable with it for some specific tasks. It's not a matter of syntax, ip-link is device-oriented and brctl is bridge-oriented. If you want to show a list of bridges and basic information about enslaved ports, 'brctl show' will do this for you. With ip-link, you'll need to iterate over devices, and list ports and information for each of them, while getting a significant amount of unwanted information in the process. However, getting ip-link to do something different would make it a different tool. > We will have to maintain this compatibility layer forever if > it gets accepted and we'll never get rid of brctl this way. I see this a bit differently: we're not getting rid of bridge-utils simply because it makes little sense to do so. It's been several years now that ip-link is able to access and set all the information and states brctl uses, but this didn't make brctl obsolete, in practice. However, getting rid of bridge-utils means bridge-utils doesn't need to be maintained, and I guess that's the reason you're advocating that. This is the very reason behind this script: it's smaller and simpler than bridge-utils, and I think we can reasonably assume it's going to need almost no maintenance, being a rather dumb implementation. -- Stefano