Re: ebpf/rss.bpf.skeleton.h generated by what?

[Markus Armbruster]

Jason Wang <jasowang@redhat.com> writes:

> On Sat, May 7, 2022 at 2:58 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> On 5/7/22 08:53, Jason Wang wrote:
>> > On Sat, May 7, 2022 at 2:46 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>> >>
>> >> On 5/7/22 07:05, Jason Wang wrote:
>> >>>> If it was generated by something in the tree, it should not be committed
>> >>>> to git.  Doesn't look like it is.
>> >>> Andrew may know more.
>> >>>
>> >>> I remember it was generated by libbpf.
>> >>
>> >> What is the source?
>> >
>> > It's tools/ebpf/rss.bpf.c.

Aha:

    $ cat tools/ebpf/Makefile.ebpf
    [...]
    $(OBJS):  %.o:%.c
            $(CLANG) $(INC_FLAGS) \
                    -D__KERNEL__ -D__ASM_SYSREG_H \
                    -I../include $(LINUXINCLUDE) \
                    $(EXTRA_CFLAGS) -c $< -o -| $(LLC) -march=bpf -filetype=obj 
-o $@
            bpftool gen skeleton rss.bpf.o > rss.bpf.skeleton.h
--->        cp rss.bpf.skeleton.h ../../ebpf/

and

    $ cat docs/devel/ebpf_rss.rst
    [...]
    RSS eBPF program
    ----------------

    RSS program located in ebpf/rss.bpf.skeleton.h generated by bpftool.
    So the program is part of the qemu binary.
    Initially, the eBPF program was compiled by clang and source code located 
at tools/ebpf/rss.bpf.c.
    Prerequisites to recompile the eBPF program (regenerate 
ebpf/rss.bpf.skeleton.h):

            llvm, clang, kernel source tree, bpftool
            Adjust Makefile.ebpf to reflect the location of the kernel source 
tree

            $ cd tools/ebpf
            $ make -f Makefile.ebpf
    [...]

Together, this answers my "what" question.  It doesn't answer my next
question: why?  That one gets answered ...

>> Thanks, maybe we can reuse some of the support for cross compilation
>> that will be introduced soon.
>
> That would be better.

... here:

>                       The reason we don't auto generate during make is
> to avoid adding new dependencies (where libbpf/bpftool is not popular
> at that time).

Always, always, *always* document your reasons for doing stuff right in
the commit message, unless they are blindingly obvious.  I understand
reasons can be obvious enough to the author.  Document them anyway if
there is any chance they are not obvious to others.