Andrew Melnichenko <and...@daynix.com> writes: > Hi all, > > On Mon, Feb 20, 2023 at 11:50 AM Daniel P. Berrangé <berra...@redhat.com> > wrote: >> >> On Sun, Feb 19, 2023 at 06:20:58PM +0200, Andrew Melnychenko wrote: >> > Added a function to check the stamp in the helper. >> > eBPF helper should have a special symbol that generates during the build. >> > QEMU checks the helper and determines that it fits, so the helper >> > will produce proper output. >> >> I think this is quite limiting for in place upgrades. >> >> Consider this scenario >> >> * Host has QEMU 8.1.0 installed >> * VM is running QEMU 8.1.0 >> * QEMU 8.1.1 is released with a bug fix in the EBF program >> * Host is upgraded to QEMU 8.1.1 >> * User attempts to hotplug a NIC to the running VM >> >> IIUC this last step is going to fail because we'll be loading >> the EBF program from 8.1.1 and so its hash is different from >> that expected by the QEMU 8.1.0 that the pre-existing VM is >> running. >> >> If some changes to the EBF program are not going to be back >> compatible from the POV of the QEMU process, should we instead >> be versioning the EBF program. eg so new QEMU will ship both >> the old and new versions of the EBF program. >> > > I think it's too complicated to maintain backward compatibility with > eBPF programs in "one package". > As we can see, the eBPF skeleton may be changed not only by bugfix but > with changes in libbpf(g.e. libbpf 1.0.1+).
Hmm, what change in libbpf 1.0.1 affects the skeleton format? > This may lead to issues when with a newer environment you can't > consistently recreate the "old" skeleton. This should be detectable, though? As in, if you know that a new version breaks compatibility you just bump the version number regardless of the underlying application version? -Toke