From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: David Ahern <dsahern@gmail.com>
Cc: Quentin Monnet <quentin.monnet@netronome.com>,
Roman Gushchin <guro@fb.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@fb.com, ast@kernel.org, daniel@iogearbox.net,
kafai@fb.com
Subject: Re: [PATCH v2 net-next 4/4] bpftool: implement cgroup bpf operations
Date: Fri, 8 Dec 2017 15:30:12 -0800 [thread overview]
Message-ID: <20171208153012.0743ed43@cakuba.netronome.com> (raw)
In-Reply-To: <77e22817-4be2-ae4f-11b7-ebc4c51f39f3@gmail.com>
On Fri, 8 Dec 2017 09:52:16 -0700, David Ahern wrote:
> On 12/8/17 8:39 AM, Quentin Monnet wrote:
> > I don't believe compatibility is an issue here, since the program and
> > its documentation come together (so they should stay in sync) and are
> > part of the kernel tree (so the tool should be compatible with the
> > kernel sources it comes with). My concern is that there is no way to
> > guess from the current description what the values for ATTACH_FLAG or
> > ATTACH_TYPE can be, without reading the source code of the program—which
> > is not exactly user-friendly.
>
> The tool should be backward and forward compatible across kernel
> versions. Running a newer command on an older kernel should fail in a
> deterministic. While the tool is in the kernel tree for ease of
> development, that should not be confused with having a direct tie to any
> kernel version.
>
> I believe man pages do include kernel version descriptions in flags
> (e.g., man 7 socket -- flags are denoted with "since Linux x.y") which
> is one way to handle it with the usual caveat that vendors might have
> backported support to earlier kernels.
Let's see if I understand correctly. We have a list of hard coded
strings which the tool will recognize (static const char * const
attach_type_strings[]). We should put that list into the man page and
help so users know what values are possible. And in the "verbose"
part of the man section mark each flag with kernel version it was
introduced in.
Roman, would you agree this is the best way forward?
next prev parent reply other threads:[~2017-12-08 23:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-07 18:39 [PATCH v2 net-next 0/4] bpftool: cgroup bpf operations Roman Gushchin
2017-12-07 18:39 ` [PATCH v2 net-next 1/4] libbpf: add ability to guess program type based on section name Roman Gushchin
2017-12-08 10:33 ` Quentin Monnet
2017-12-07 18:39 ` [PATCH v2 net-next 2/4] libbpf: prefer global symbols as bpf program name source Roman Gushchin
2017-12-07 18:39 ` [PATCH v2 net-next 3/4] bpftool: implement prog load command Roman Gushchin
2017-12-07 21:55 ` Jakub Kicinski
2017-12-08 10:33 ` Quentin Monnet
2017-12-07 18:39 ` [PATCH v2 net-next 4/4] bpftool: implement cgroup bpf operations Roman Gushchin
2017-12-07 19:22 ` David Ahern
2017-12-07 22:23 ` Jakub Kicinski
2017-12-07 23:00 ` Philippe Ombredanne
2017-12-08 14:17 ` Roman Gushchin
2017-12-08 10:34 ` Quentin Monnet
2017-12-08 13:56 ` Philippe Ombredanne
2017-12-08 14:53 ` Roman Gushchin
2017-12-08 14:12 ` Roman Gushchin
2017-12-08 15:39 ` Quentin Monnet
2017-12-08 16:52 ` David Ahern
2017-12-08 23:30 ` Jakub Kicinski [this message]
2017-12-09 19:19 ` Roman Gushchin
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=20171208153012.0743ed43@cakuba.netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=dsahern@gmail.com \
--cc=guro@fb.com \
--cc=kafai@fb.com \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=quentin.monnet@netronome.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.