From: Jakub Kicinski <email@example.com> To: Phil Sutter <firstname.lastname@example.org> Cc: Jesper Dangaard Brouer <email@example.com>, Daniel Borkmann <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Jakub Kicinski <email@example.com>, Quentin Monnet <firstname.lastname@example.org> Subject: Re: [PATCH bpf-next v3 05/11] bpf: avoid retpoline for lookup/update/delete calls on maps Date: Mon, 4 Jun 2018 11:25:24 -0700 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <20180604110225.GX11363@tatos.vnet> On Mon, 4 Jun 2018 13:02:25 +0200, Phil Sutter wrote: > On Sun, Jun 03, 2018 at 07:08:55PM +0200, Jesper Dangaard Brouer wrote: > > Secondly I personally *hate* how the 'ip' does it's short options > > parsing and especially order/precedence ambiguity. Phil Sutter > > (Fedora/RHEL iproute2 maintainer) have a funny quiz illustrating the > > ambiguity issues. > > Hehe, yes. It's a classical case of something smart evolving into a > pain: At first there's only 'ip link', so you allow 'ip l' as a > shortcut. Then someone implements 'ip l2tp' - so what do you do? Good example, I like that "ip l" shows me the links because that's what 99.99% of people want when they type that command ;) > Establish a policy of abbreviation having to be unique and break > existing behaviour or accept the mess and head on. Commands are tested in order of addition so older ones take precedence. The iproute2 behaviour was replicated in bpftool on purpose, because it should be very familiar to people. It is to me at least. And IMHO it's better to be consistent with a well known tool than have our own quirks and rules... > My suggestion would be to not get into the abbreviated subcommands > business at all but instead ship and maintain a bash-completion script. We prefer to have both :) Those of us who like to abbreviate can do that, and others can use completions. I personally think Quentin did an awesome job on the completions, they cover the entire syntax unlike the iproute2 ones and we intend to keep them that way!
next prev parent reply other threads:[~2018-06-04 18:25 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-06-02 21:06 [PATCH bpf-next v3 00/11] Misc BPF improvements Daniel Borkmann 2018-06-02 21:06 ` [PATCH bpf-next v3 01/11] bpf: test case for map pointer poison with calls/branches Daniel Borkmann 2018-06-02 21:06 ` [PATCH bpf-next v3 02/11] bpf: add also cbpf long jump test cases with heavy expansion Daniel Borkmann 2018-06-02 21:06 ` [PATCH bpf-next v3 03/11] bpf: fixup error message from gpl helpers on license mismatch Daniel Borkmann 2018-06-02 21:06 ` [PATCH bpf-next v3 04/11] bpf: show prog and map id in fdinfo Daniel Borkmann 2018-06-02 21:06 ` [PATCH bpf-next v3 05/11] bpf: avoid retpoline for lookup/update/delete calls on maps Daniel Borkmann 2018-06-03 6:56 ` Jesper Dangaard Brouer 2018-06-03 16:11 ` Daniel Borkmann 2018-06-03 17:08 ` Jesper Dangaard Brouer 2018-06-04 11:02 ` Phil Sutter 2018-06-04 18:25 ` Jakub Kicinski [this message] 2018-06-04 19:45 ` Daniel Borkmann 2018-06-04 22:36 ` David Ahern 2018-06-02 21:06 ` [PATCH bpf-next v3 06/11] bpf: add bpf_skb_cgroup_id helper Daniel Borkmann 2018-06-02 21:06 ` [PATCH bpf-next v3 07/11] bpf: make sure to clear unused fields in tunnel/xfrm state fetch Daniel Borkmann 2018-06-02 21:06 ` [PATCH bpf-next v3 08/11] bpf: fix cbpf parser bug for octal numbers Daniel Borkmann 2018-06-02 21:06 ` [PATCH bpf-next v3 09/11] bpf: fix context access in tracing progs on 32 bit archs Daniel Borkmann 2018-06-02 21:06 ` [PATCH bpf-next v3 10/11] bpf: sync bpf uapi header with tools Daniel Borkmann 2018-06-02 21:06 ` [PATCH bpf-next v3 11/11] bpf, doc: add missing patchwork url and libbpf to maintainers Daniel Borkmann 2018-06-03 15:08 ` [PATCH bpf-next v3 00/11] Misc BPF improvements Alexei Starovoitov
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH bpf-next v3 05/11] bpf: avoid retpoline for lookup/update/delete calls on maps' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).