From: Stefano Brivio <sbrivio@redhat.com>
To: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Cc: David Ahern <dsahern@gmail.com>, Phil Sutter <phil@nwl.cc>,
Eric Garver <egarver@redhat.com>,
Tomas Dolezal <todoleza@redhat.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Lennert Buytenhek <buytenh@gnu.org>,
netdev@vger.kernel.org
Subject: Re: [PATCH iproute2-next] Introduce ip-brctl shell script
Date: Fri, 25 Jan 2019 11:04:37 +0100 [thread overview]
Message-ID: <20190125110437.0f362a20@elisabeth> (raw)
In-Reply-To: <800cb3d3-c749-3f36-83ea-0375e67fbd33@cumulusnetworks.com>
Hi Nik,
On Wed, 23 Jan 2019 17:09:42 +0200
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> 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
next prev parent reply other threads:[~2019-01-25 10:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-18 17:00 [PATCH iproute2-next] Introduce ip-brctl shell script Stefano Brivio
2019-01-23 15:09 ` Nikolay Aleksandrov
2019-01-23 16:33 ` Roopa Prabhu
2019-01-25 10:05 ` Stefano Brivio
2019-01-28 5:08 ` Roopa Prabhu
2019-01-28 7:57 ` Stefano Brivio
2019-01-30 22:30 ` Roopa Prabhu
2019-01-31 12:46 ` Stefano Brivio
2019-01-31 16:28 ` Roopa Prabhu
2019-02-05 22:50 ` Stephen Hemminger
2019-02-06 10:55 ` Stefano Brivio
2019-01-25 10:04 ` Stefano Brivio [this message]
2019-01-30 4:51 ` David Ahern
2019-01-30 10:55 ` Stefano Brivio
2019-01-31 5:12 ` David Ahern
2019-01-31 12:46 ` Stefano Brivio
2019-01-31 12:49 ` Stefano Brivio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190125110437.0f362a20@elisabeth \
--to=sbrivio@redhat.com \
--cc=buytenh@gnu.org \
--cc=dsahern@gmail.com \
--cc=egarver@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=phil@nwl.cc \
--cc=stephen@networkplumber.org \
--cc=todoleza@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.