On Mon, May 9, 2022 at 1:27 PM Markus Armbruster <[email protected]> wrote: > > Jason Wang <[email protected]> writes: > > > On Sat, May 7, 2022 at 2:58 PM Paolo Bonzini <[email protected]> wrote: > >> > >> On 5/7/22 08:53, Jason Wang wrote: > >> > On Sat, May 7, 2022 at 2:46 PM Paolo Bonzini <[email protected]> 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. >
Ok. Andrew, want to post a patch to explain this? Thanks
