[DTrace-devel] [PATCH 08/12] Remove libbpf dependency

Kris Van Hees kris.van.hees at oracle.com
Sun Jul 17 04:51:41 UTC 2022


On Sat, Jul 16, 2022 at 01:52:15PM -0700, Eugene Loh via DTrace-devel wrote:
> Again, sorry for the weirdly formatted replies:  this is another patch that
> never appeared in my inbox.
> 
> Reviewed-by: Eugene Loh <eugene.loh at oracle.com>
> 
> A few comments:
> 
> *)  In file CODING-STYLE, the last three lines can be removed.
>     They are (including a blank line):
> 
>         Code in libbpf/ need not conform to the guidelines in this document,
> since
>         we expect not to retain that code in the long term.

Ah yes, thanks.

> *)  In libdtrace/dt_bpf.c, you comment out
> 
>         /* #include <bpf.h> */
> 
>     That line can be removed entirely.

Yes, I forgot to do that.

> *)  In libdtrace/dt_bpf.c, in dt_bpf_prog_load(), you have
> 
>         do {
>                 fd = bpf(BPF_PROG_LOAD, &attr);
>         } while (fd < 0 && errno == EAGAIN);
> 
>     I do not see the EAGAIN case documented in the bpf() man page.
>     Where is this behavior described?

bpf() is a syscall, and therefore it can fail with errno EAGAIN.

>     Also, do we really want an endless loop here?  Maybe there should
>     be a time-out or a limited number of retries?

It is almost certainly safe, but I agree that it is even safer if we put a
limit on the number of retries.  I'll add that.

> *)  Finally, it's a little confusing to have both dt_bpf_load_prog() and
>     dt_bpf_prog_load(), but perhaps the confusion is worth the hassle of
>     coming up with different names and changing stuff.  I don't know.
>     It looks funny, but can stay the way it is.

Yes, the naming gets a bit strange but I don't think it is that difficult to
figure out either and I honestly don't know what names would make it much
better.  I'll stick with it as-is for now.



More information about the DTrace-devel mailing list