linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Vernet <void@manifault.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	Jonathan Corbet <corbet@lwn.net>,
	bpf@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [RFC PATCH v3] Documentation/bpf: Document API stability expectations for kfuncs
Date: Thu, 2 Feb 2023 10:37:20 -0600	[thread overview]
Message-ID: <Y9vmwDzb0jhjpEyk@maniforge> (raw)
In-Reply-To: <875yckth7n.fsf@toke.dk>

On Thu, Feb 02, 2023 at 12:55:08PM +0100, Toke Høiland-Jørgensen wrote:
> David Vernet <void@manifault.com> writes:
> 
> > On Wed, Feb 01, 2023 at 06:44:48PM +0100, Toke Høiland-Jørgensen wrote:
> >> Following up on the discussion at the BPF office hours (and subsequent
> >> discussion), this patch adds a description of API stability expectations
> >> for kfuncs. The goal here is to manage user expectations about what kind of
> >> stability can be expected for kfuncs exposed by the kernel.
> >> 
> >> Since the traditional BPF helpers are basically considered frozen at this
> >> point, kfuncs will be the way all new functionality will be exposed to BPF
> >> going forward. This makes it important to document their stability
> >> guarantees, especially since the perception up until now has been that
> >> kfuncs should always be considered "unstable" in the sense of "may go away
> >> or change at any time". Which in turn makes some users reluctant to use
> >> them because they don't want to rely on functionality that may be removed
> >> in future kernel versions.
> >> 
> >> This patch adds a section to the kfuncs documentation outlining how we as a
> >> community think about kfunc stability. The description is a bit vague and
> >> wishy-washy at times, but since there does not seem to be consensus to
> >> commit to any kind of hard stability guarantees at this point, I feat this
> >> is the best we can do.
> >> 
> >> I put this topic on the agenda again for tomorrow's office hours, but
> >> wanted to send this out ahead of time, to give people a chance to read it
> >> and think about whether it makes sense or if there's a better approach.
> >> 
> >> Previous discussion:
> >> https://lore.kernel.org/r/20230117212731.442859-1-toke@redhat.com
> >
> > Again, thanks a lot for writing this down and getting a real / tangible
> > conversation started.
> 
> You're welcome! Just a few quick notes on one or two points below, we
> can continue the discussion at the office hours:

Hey Toke,

Sounds good, I just read over your notes / points and am happy to
discuss more in office hours as you suggested. Just wanted to give you a
heads up well that just I sent out a proposal which you can read in [0].

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

I know it's short notice (sorry about that, did my best to get it all
ready as soon as possible before office hours), but if you happen to
have time to read over it before we meet that would be great. If not, no
worries, I can just tell you the gist of what I'm proposing when we talk
in office hours in half an hour.

Thanks,
David

      reply	other threads:[~2023-02-02 16:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01 17:44 [RFC PATCH v3] Documentation/bpf: Document API stability expectations for kfuncs Toke Høiland-Jørgensen
2023-02-02  5:25 ` David Vernet
2023-02-02 11:55   ` Toke Høiland-Jørgensen
2023-02-02 16:37     ` David Vernet [this message]

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=Y9vmwDzb0jhjpEyk@maniforge \
    --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=kpsingh@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=toke@redhat.com \
    --cc=yhs@fb.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;
as well as URLs for NNTP newsgroup(s).