On Mon, May 24, 2021 at 2:34 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: > > > On Mon, May 24, 2021 at 1:53 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > >> > >> Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: > >> > >> > On Sun, May 23, 2021 at 11:36 PM John Fastabend > >> > <john.fastabend@xxxxxxxxx> wrote: > >> >> > >> >> Andrii Nakryiko wrote: > >> >> > Implement error reporting changes discussed in "Libbpf: the road to v1.0" > >> >> > ([0]) document. > >> >> > > >> >> > Libbpf gets a new API, libbpf_set_strict_mode() which accepts a set of flags > >> >> > that turn on a set of libbpf 1.0 changes, that might be potentially breaking. > >> >> > It's possible to opt-in into all current and future 1.0 features by specifying > >> >> > LIBBPF_STRICT_ALL flag. > >> >> > > >> >> > When some of the 1.0 "features" are requested, libbpf APIs might behave > >> >> > differently. In this patch set a first set of changes are implemented, all > >> >> > related to the way libbpf returns errors. See individual patches for details. > >> >> > > >> >> > Patch #1 adds a no-op libbpf_set_strict_mode() functionality to enable > >> >> > updating selftests. > >> >> > > >> >> > Patch #2 gets rid of all the bad code patterns that will break in libbpf 1.0 > >> >> > (exact -1 comparison for low-level APIs, direct IS_ERR() macro usage to check > >> >> > pointer-returning APIs for error, etc). These changes make selftest work in > >> >> > both legacy and 1.0 libbpf modes. Selftests also opt-in into 100% libbpf 1.0 > >> >> > mode to automatically gain all the subsequent changes, which will come in > >> >> > follow up patches. > >> >> > > >> >> > Patch #3 streamlines error reporting for low-level APIs wrapping bpf() syscall. > >> >> > > >> >> > Patch #4 streamlines errors for all the rest APIs. > >> >> > > >> >> > Patch #5 ensures that BPF skeletons propagate errors properly as well, as > >> >> > currently on error some APIs will return NULL with no way of checking exact > >> >> > error code. > >> >> > > >> >> > [0] https://docs.google.com/document/d/1UyjTZuPFWiPFyKk1tV5an11_iaRuec6U-ZESZ54nNTY > >> >> > > >> >> > Andrii Nakryiko (5): > >> >> > libbpf: add libbpf_set_strict_mode() API to turn on libbpf 1.0 > >> >> > behaviors > >> >> > selftests/bpf: turn on libbpf 1.0 mode and fix all IS_ERR checks > >> >> > libbpf: streamline error reporting for low-level APIs > >> >> > libbpf: streamline error reporting for high-level APIs > >> >> > bpftool: set errno on skeleton failures and propagate errors > >> >> > > >> >> > >> >> LGTM for the series, > >> >> > >> >> Acked-by: John Fastabend <john.fastabend@xxxxxxxxx> > >> > > >> > Thanks, John! > >> > > >> > Toke, Stanislav, you cared about these aspects of libbpf 1.0 (by > >> > commenting on the doc itself), do you mind also taking a brief look > >> > and letting me know if this works for your use cases? Thanks! > >> > >> Changes LGTM: > >> > >> Acked-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx> > >> > >> As a side note, the series seems to have been chopped up into individual > >> emails with no threading; was a bit weird that I had to go hunting for > >> the individual patches in my mailbox... > >> > > > > That's my bad, I messed up and sent them individually and probably > > that's why they weren't threaded properly. > > Right, OK, I'll stop looking for bugs on my end, then :) > > BTW, one more thing that just came to mind: since that gdoc is not > likely to be around forever, would it be useful to make the reference in > the commit message(s) point to something more stable? IDK what that > shoul be, really. Maybe just pasting (an abbreviated outline of?) the > text in the document into the cover letter / merge commit could work? I was hoping Google won't deprecate Google Docs any time soon and I had no intention to remove that document. But I was also thinking to start wiki page at github.com/libbpf/libbpf with migration instructions, so once that is up and running I can link that from libbpf_set_strict_mode() doc comment. But I'd like to avoid blocking on that. > > -Toke >
