Dne 05. 11. 20 v 13:03 Daniel P. Berrangé napsal(a):
On Tue, Nov 03, 2020 at 11:58:54AM +0100, Fabio Valentini wrote:
On Tue, Nov 3, 2020 at 11:49 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
In QEMU there's a desire to make use of BPF programs for implementing
some networking features. The current patches are proposing adding
prebuilt BPF byte code to the QEMU repo, with source available, but
not actually building from source during a build.
I was wondering if we had any specific guidance or rules covering the
shipping BPF programs in particular ?
To me it feels like BPF programs should fall under normal Fedora
practice that expects everything to be built from master source.
We do have the exception that allows firmware to be shipped as
pre-built blobs, but I'm thinking that BPF programs could not
be considered as firmware.
Has this been discussed before, if so can someone point to the
results, as I'm not finding anything specific to BPF programs and
Fedora packaging via Google.
If there are no specialized Packaging Guidelines for something, then
the general guidelines apply - so in this case, compiling from source
is required, since Fedora packages MUST NOT ship precompiled binaries.
It seems this case is a little more fuzzy in terms of what is
considered "the preferred source" format, and whether the BPF
program is in fact considered a "binary" at all.
I think that the best would be if the "binary" was stripped from the
guidelines. Because, you could somewhat argue about JARs or GEM and I
believe, that this guideline should apply also to documentation as well
as various grammar parsers generators etc.
Vít
There is the "dpdk" package in Fedora which is doing similar to
what is being proposed for QEMU.
In dpdk-stable-19.11.3/drivers/net/tap/tap_bpf_program.c there is
BPF "source code".
This was, at some point in time, apparently compiled using some
undefined process to create a binary byte code blob.
This binary blob was then processed, again by some undefined process,
to extract just the BPF instructions, which are then turned back
into "source code" as a static byte array in a C header file. The
latter is what is actually compiled. This derived source is in the
dpdk-stable-19.11.3/drivers/net/tap/tap_bpf_insns.h
Given that dpdk is not providing any build process for going from
tap_bpf_program.c to tap_bpf_insns.h, it looks to me like the upstream
project effectively considers "tap_bpf_insns.h" to be their preferred
source form, and tap_bpf_program.c as just a reference for its
original creation.
IOW, to me it looks like this embedded BPF program shouldn't be
considered a binary from Fedora POV and can be used as is.
Regards,
Daniel
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
