From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: bpf <bpf@vger.kernel.org>
Cc: Kernel Team <kernel-team@fb.com>
Subject: libbpf: the road to v1.0
Date: Wed, 24 Feb 2021 11:44:10 -0800 [thread overview]
Message-ID: <CAEf4BzZ+jJs7-HtjVLzcevmGf78PHxEsrk66FwKvy6FCsiU=nQ@mail.gmail.com> (raw)
Hi all,
So I've been ruminating on getting libbpf to 1.0 version for a while
now and finally got to write down most of the major (and not so much)
things I wanted to change and/or break, given v1.0 gives an
opportunity to break API/ABI compatibility, where necessary.
I decided to share this with the community in the form of a Google Doc
(check [0]), open to commenting by anyone, because there are many
different things, quite often completely independent from each other.
So email doesn't feel like the right medium to have a discussion given
the amount of people that might be interested about just pieces of the
plan.
The overarching idea is to streamline APIs, make them overall more
consistent throughout, as well as eliminate some very common pitfalls.
Any such changes means potentially more pain for existing users during
the transition period. I realize that, but I hope everyone will keep
in mind the longer term goal of making libbpf easier to use both for
the new and existing users.
My intent is to spend some time in discussions and see what I have
missed and what would be argued to be too drastic/problematic. So the
plan is not set in stone and can/will be adjusted (within reason, of
course, I don't believe everyone is going to converge and be happy
about all the changes, but that's OK). But once decided on the plan, I
(and hopefully others will help) will start implementing changes, will
probably create a wiki page documenting API migration paths, etc, etc.
My current thinking is to do a gradual transition, rather than a big
bang breaking change in 1.0 release. This should give people more time
to find any possible breakages and adopt their code base gradually, so
that by the 1.0 time there isn't much surprise left. But feel free to
argue the other way.
BTW, that document is only describing potentially breaking changes, it
doesn't mean libbpf won't get any other new functionality. I still
plan a bunch of other (new) features to be added before v1.0. E.g.,
stuff like BPF static linking support (merging together multiple BPF
.o files) and declarative PROG_ARRAY map initialization pops to mind
immediately.
So, please check the document, leave comments, make yourself aware of
upcoming changes. Thank you!
[0] https://docs.google.com/document/d/1UyjTZuPFWiPFyKk1tV5an11_iaRuec6U-ZESZ54nNTY/edit?usp=sharing
-- Andrii
next reply other threads:[~2021-02-24 19:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-24 19:44 Andrii Nakryiko [this message]
2021-06-02 5:58 ` libbpf: the road to v1.0 Andrii Nakryiko
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='CAEf4BzZ+jJs7-HtjVLzcevmGf78PHxEsrk66FwKvy6FCsiU=nQ@mail.gmail.com' \
--to=andrii.nakryiko@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=kernel-team@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).