On Sun, Sep 02, 2018 at 11:13:16AM +0200, Gregor Jasny wrote: > Hello Debian Mentors, > > I'm writing because I seek advice on how to properly package Berkeley > Packet Filter objects. I was not able to find prior art in any other > Debian package. > > The v4l-utils source package contains a program called ir-keytable which > could be used to alter in-kernel infrared decoder tables. Recently a new > feature was merged into 4.18 Kernel that allows arbitrary protocol > decoding using the Berkeley Packet Filter: > https://lwn.net/Articles/759188/ > > The ir-keytable source contains some BPF source files that gets compiled > into BPF code using clang: > > $(CLANG) ... -target bpf -O2 -c $< > > The result are the following files: > > debian/ir-keytable/lib/udev/rc_keymaps/protocols/manchester.o > > debian/ir-keytable/lib/udev/rc_keymaps/protocols/grundig.o > > debian/ir-keytable/lib/udev/rc_keymaps/protocols/pulse_length.o > > debian/ir-keytable/lib/udev/rc_keymaps/protocols/rc_mm.o > > debian/ir-keytable/lib/udev/rc_keymaps/protocols/pulse_distance.o > > I'd like to know if you have suggestions how to properly package them. > Where should they stay according to FHS? Should I keep the .o suffix or > should I replace it with something like .bpf?
Just wanted to add that there is a generic bpf tool in the linux kernel tree called bpftool. This can be used for loading bpf programs, listing all loaded programs, dump loaded programs, etc. It is very possible that users will want this packaged: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/bpf/bpftool/Documentation/bpftool.rst Now, this program refers to bpf programs as "object file". For example, here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/bpf/bpftool/prog.c#n821 The bpf samples provided in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/samples/bpf/Makefile Also use .o for bpf programs. Lastely note these presentations: https://blog.linuxplumbersconf.org/2015/ocw/system/presentations/3249/original/bpf_llvm_2015aug19.pdf https://archive.fosdem.org/2016/schedule/event/ebpf/attachments/slides/1159/export/events/attachments/ebpf/slides/1159/ebpf.pdf All of them talk about "clang -O2 -target bpf -o foo.o foo.c", so .o is kind of expected. I suspect ir-keytable is the first package to come across this question, and there will be many more. Thanks, Sean > > Theoretically one could make an ir-keytable-filters package with > Architecture: all and Multi-Arch: foreign but I wonder if it's worth the > effort for 36 KB of data. > > dpkg-shlibdeps seems to have some problems: > > objdump: debian/ir-keytable/lib/udev/rc_keymaps/protocols/pulse_length.o: > > not a dynamic object > > objdump: debian/ir-keytable/lib/udev/rc_keymaps/protocols/pulse_length.o: > > invalid operation > > dpkg-shlibdeps: warning: couldn't parse dynamic symbol definition: no > > symbols > > As well as Lintian: > > E: ir-keytable: binary-from-other-architecture > > lib/udev/rc_keymaps/protocols/grundig.o > > Maybe a .bpf file suffix could help to accept those at certain whitelisted > locations. > > Thanks for your input! > > -Gregor