Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753006AbdLHQwS (ORCPT ); Fri, 8 Dec 2017 11:52:18 -0500 Received: from mail-pg0-f67.google.com ([74.125.83.67]:43246 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752342AbdLHQwR (ORCPT ); Fri, 8 Dec 2017 11:52:17 -0500 X-Google-Smtp-Source: AGs4zMawAOaUTIxPFOSaqWl0M0yb8lft+RlQbVvvpaQrWfhBW2cdcCOb9fMHLkXlzR94dYldNf5nzw== Subject: Re: [PATCH v2 net-next 4/4] bpftool: implement cgroup bpf operations To: Quentin Monnet , Roman Gushchin Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, ast@kernel.org, daniel@iogearbox.net, jakub.kicinski@netronome.com, kafai@fb.com References: <20171207183909.16240-1-guro@fb.com> <20171207183909.16240-5-guro@fb.com> <20171208141251.GA9458@castle> <0eed580a-804b-329e-7bfc-1dc5c09a1deb@netronome.com> From: David Ahern Message-ID: <77e22817-4be2-ae4f-11b7-ebc4c51f39f3@gmail.com> Date: Fri, 8 Dec 2017 09:52:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <0eed580a-804b-329e-7bfc-1dc5c09a1deb@netronome.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1048 Lines: 20 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.