On Sat, Oct 5, 2019 at 10:10 AM Alexei Starovoitov <ast@xxxxxx> wrote: > > On 10/5/19 12:59 AM, Andrii Nakryiko wrote: > > Get rid of list of BPF helpers in bpf_helpers.h (irony...) and > > auto-generate it into bpf_helpers_defs.h, which is now included from > > bpf_helpers.h. > > > > Suggested-by: Alexei Starovoitov<ast@xxxxxx> > > Signed-off-by: Andrii Nakryiko<andriin@xxxxxx> > > --- > > tools/lib/bpf/Makefile | 8 +- > > tools/lib/bpf/bpf_helpers.h | 264 +-- > > tools/lib/bpf/bpf_helpers_defs.h | 2677 ++++++++++++++++++++++++++++++ > > 3 files changed, 2685 insertions(+), 264 deletions(-) > > create mode 100644 tools/lib/bpf/bpf_helpers_defs.h > > Approach looks good to me. > imo that's better than messing with macros. > > Using bpf_helpers_doc.py as part of build will help man pages too. > I think we were sloppy documenting helpers, since only Quentin > was running that script regularly. Yep, I agree, I had to fix few things, as well as (char *) vs (void *) vs (__u8 *) differences were causing some extra warnings. Please check the list of type translations whether they make sense. > > Only question is what is the reason to commit generated .h into git? So originally I didn't want to depend on system UAPI headers during Github build. But now I recalled that we do have latest UAPI synced into Github's include/ subdir, so that's not an obstacle really. We'll just need to re-license bpf_helpers_doc.py (I don't think Quentin will mind) and start syncing it to Github (not a big deal at all). There is still a benefit in having it checked in: easy to spot if script does something wrong and double-check the changes (after initial big commit, of course). If you think that's not reason enough, let me know and I can drop it in v2.
