All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Andrey Ignatov <rdna@fb.com>
Cc: netdev@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
	yhs@fb.com, kafai@fb.com, kernel-team@fb.com
Subject: Re: [PATCH bpf-next v2 0/4] libbpf: ABI versioning and documentation
Date: Mon, 26 Nov 2018 19:06:52 -0800	[thread overview]
Message-ID: <20181127030650.hr6ihkfnlj6dct7c@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <cover.1543019933.git.rdna@fb.com>

On Fri, Nov 23, 2018 at 04:44:31PM -0800, Andrey Ignatov wrote:
> This patch set adds ABI versioning and documentation to libbpf.
> 
> Patch 1 renames btf_get_from_id to btf__get_from_id to follow naming
> convention.
> Patch 2 adds version script and has more details on ABI versioning.
> Patch 3 adds simple check that all global symbols are versioned.
> Patch 4 documents a few aspects of libbpf API and ABI in dev process.
> 
> v1->v2:
> * add patch from Martin KaFai Lau <kafai@fb.com> to rename btf_get_from_id;
> * add documentation for libbpf API and ABI.

All looks great to me.
Thank you for adding the doc.
Applied to bpf-next.

We need to discuss the release model and version bumps.
For example I don't think it's necessary to bump the version
and update libbpf.map every time the new function is added.
I mean we can synchronize release of libbpf with the release of the kernel
or release it every N weeks.
So if we add new api functions during this release we can simply
add them to libbpf.map while keeping the version as 0.0.1

I'd also consider the first 0.0.1 release to be experimental
while we're figuring out the right process.
For the next kernel/libbpf release I propose to bump it to 1.0.0

Another idea is to version it just like kernel and make libbpf version
always equal kernel version.
But I think that would be an overkill. libbpf isn't tightly coupled to
the kernel. Like we just merged the patch (prog_name/map_name probing
that allows new libbpf to work with older kernel.

  parent reply	other threads:[~2018-11-27 14:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-24  0:44 [PATCH bpf-next v2 0/4] libbpf: ABI versioning and documentation Andrey Ignatov
2018-11-24  0:44 ` [PATCH bpf-next v2 1/4] libbpf: Name changing for btf_get_from_id Andrey Ignatov
2018-11-24  0:44 ` [PATCH bpf-next v2 2/4] libbpf: Add version script for DSO Andrey Ignatov
2018-11-24  0:44 ` [PATCH bpf-next v2 3/4] libbpf: Verify versioned symbols Andrey Ignatov
2018-11-24  0:44 ` [PATCH bpf-next v2 4/4] libbpf: Document API and ABI conventions Andrey Ignatov
2018-11-27  3:06 ` Alexei Starovoitov [this message]
2018-11-27 11:36   ` [PATCH bpf-next v2 0/4] libbpf: ABI versioning and documentation Daniel Borkmann
2018-12-03  2:27     ` Andrey Ignatov

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=20181127030650.hr6ihkfnlj6dct7c@ast-mbp.dhcp.thefacebook.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kafai@fb.com \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=rdna@fb.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 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.