On Tue, Jul 27, 2021 at 9:49 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Mon, Jul 26, 2021 at 12:38 PM Andrii Nakryiko > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > On Tue, Jul 20, 2021 at 5:08 PM Alexei Starovoitov > > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > > From: Alexei Starovoitov <ast@xxxxxxxxxx> > > > > > > Split CO-RE processing logic from libbpf into separate file > > > with an interface that doesn't dependend on libbpf internal details. > > > As the next step relo_core.c will be compiled with libbpf and with the kernel. > > > The _internal_ interface between libbpf/CO-RE and kernel/CO-RE will be: > > > int bpf_core_apply_relo_insn(const char *prog_name, struct bpf_insn *insn, > > > int insn_idx, > > > const struct bpf_core_relo *relo, > > > int relo_idx, > > > const struct btf *local_btf, > > > struct bpf_core_cand_list *cands); > > > where bpf_core_relo and bpf_core_cand_list are simple types > > > prepared by kernel and libbpf. > > > > > > Though diff stat shows a lot of lines inserted/deleted they are moved lines. > > > Pls review with diff.colorMoved. > > > > > > Alexei Starovoitov (4): > > > libbpf: Cleanup the layering between CORE and bpf_program. > > > libbpf: Split bpf_core_apply_relo() into bpf_program indepdent helper. > > > libbpf: Move CO-RE types into relo_core.h. > > > libbpf: Split CO-RE logic into relo_core.c. > > > > > > > LGTM. Applied to bpf-next, fixed typo in patch 3 subject, and also > > made few adjustments. Let me know if you object to any of them: > > > > 1. I felt like the original copyright year should be preserved when > > moving code into a new file, so I've changed relo_core.h's year to > > 2019. Hope that's fine. > > 2. relo_core.c didn't have a Copyright line, so I added the /* > > Copyright (c) 2019 Facebook */ as well. > > 3. I trimmed down the list of #includes in core_relo.c, because most > > of them were absolutely irrelevant and just preserved as-is from > > libbpf.c Everything seems to compile just fine without those. > > Thanks! Much appreciate it. > It was on my todo list. I lazily copy-pasted them to avoid > accidental breakage on some archs that I don't have access to > (since I didn't wait for the kernel build bot to process them before I > sent them). > fyi intel folks can include your private tree as well, so you'd have to respin > your patches due to odd 32-bit build breakage. Just email them with > your git tree location. yeah, that's a good idea, I'll email them
