public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Vernet <void@manifault.com>
To: bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	martin.lau@linux.dev, song@kernel.org, yhs@meta.com,
	john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com,
	haoluo@google.com, jolsa@kernel.org,
	linux-kernel@vger.kernel.org, kernel-team@meta.com,
	toke@redhat.com, brouer@redhat.com, corbet@lwn.net,
	linux-doc@vger.kernel.org
Subject: [PATCH bpf-next v2 0/1] Document kfunc lifecycle / stability expectations
Date: Thu,  2 Feb 2023 16:35:56 -0600	[thread overview]
Message-ID: <20230202223557.744110-1-void@manifault.com> (raw)

This is the v2 of the proposal for documenting BPF kfunc lifecycle and
stability. v1 of this proposal can be found in [0]. As [0] indicates,
Toke has also provided several RFC proposals, the most recent of which
is can be found in [1].

Much of this proposal is based on Toke's prior patches on this topic,
and group discussions at BPF office hours. Anyone who participated
in either prior proposals for kfunc lifecycle / stability documentation,
or in BPF office-hour discussions, may feel free to submit
Co-developed-by tags in place of Acked-by, Reviewed-by, etc.

Changelog
---------
v1 -> v2:
- Move some of the main points of the arguments around. v1 underscored
  quite strongly that kfuncs don't have _any_ stability guarantees.
  While true, it may scare away users who misinterpret the implications
  of that to mean that things will change wildly and at any time.
  Reframe the general flow of the section to still be clear that no
  stability is guaranteed, but front-load the content that clarifies why
  this isn't necessarily something to be afraid of (Toke, Daniel, and
  others).
- Add a paragraph explaining that out-of-tree BPF programs that use
  kfuncs are relevant to discussions surrounding whether kfuncs should
  be modified or removed. While the onus is on kfunc users to explicitly
  engage with the upstream community to let them know which kfuncs
  they're using and why they're useful, the added paragraph also makes
  it clear that the BPF community will in turn participate in upstream
  discussions to ensure that such users aren't equated with out-of-tree
  module users and outright ignored. Also make it clear that our hope is
  that BPF programs will be upstreamed on a more regular basis (Toke,
  Daniel, and others).
- Remove patches that add KF_DEPRECATED flag to <linux/btf.h>. They'll
  remain in the documentation for now, and will be merged at a later
  time when it's actually a useful signal for developers (Alexei).

[0]: https://lore.kernel.org/all/20230202163056.658641-1-void@manifault.com/
[1]: https://lore.kernel.org/all/20230201174449.94650-1-toke@redhat.com/

David Vernet (1):
  bpf/docs: Document kfunc lifecycle / stability expectations

 Documentation/bpf/kfuncs.rst | 139 +++++++++++++++++++++++++++++++++--
 1 file changed, 134 insertions(+), 5 deletions(-)

-- 
2.39.0


             reply	other threads:[~2023-02-02 22:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-02 22:35 David Vernet [this message]
2023-02-02 22:35 ` [PATCH bpf-next v2] bpf/docs: Document kfunc lifecycle / stability expectations David Vernet
2023-02-03  2:14   ` Bagas Sanjaya
2023-02-03 10:48   ` Donald Hunter
2023-02-03 14:14     ` David Vernet
2023-02-03 13:04   ` Toke Høiland-Jørgensen
2023-02-03 14:47     ` David Vernet
2023-02-03 14:56       ` David Vernet

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=20230202223557.744110-1-void@manifault.com \
    --to=void@manifault.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=toke@redhat.com \
    --cc=yhs@meta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox