Thread (20 messages) 20 messages, 5 authors, 2017-12-09

Re: [PATCH v2 net-next 4/4] bpftool: implement cgroup bpf operations

From: Jakub Kicinski <hidden>
Date: 2017-12-08 23:30:18
Also in: lkml

On Fri, 8 Dec 2017 09:52:16 -0700, David Ahern wrote:
On 12/8/17 8:39 AM, Quentin Monnet wrote:
quoted
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help