RE: [RFC PATCH 01/12] configure: Add iovisor/ubpf project as a submodule for QEMU

[Zhang, Chen]

> -----Original Message-----
> From: Daniel P. Berrangé <berrange@redhat.com>
> Sent: Monday, June 20, 2022 6:01 PM
> To: Zhang, Chen <chen.zhang@intel.com>
> Cc: Thomas Huth <thuth@redhat.com>; Jason Wang
> <jasowang@redhat.com>; qemu-dev <qemu-devel@nongnu.org>; Paolo
> Bonzini <pbonzini@redhat.com>; Eduardo Habkost <eduardo@habkost.net>;
> Eric Blake <eblake@redhat.com>; Markus Armbruster
> <armbru@redhat.com>; Peter Maydell <peter.maydell@linaro.org>; Laurent
> Vivier <lvivier@redhat.com>; Yuri Benditovich
> <yuri.benditovich@daynix.com>; Andrew Melnychenko
> <andrew@daynix.com>
> Subject: Re: [RFC PATCH 01/12] configure: Add iovisor/ubpf project as a
> submodule for QEMU
> 
> On Mon, Jun 20, 2022 at 09:29:05AM +0000, Zhang, Chen wrote:
> >
> > >
> > > On 20/06/2022 10.11, Daniel P. Berrangé wrote:
> > > > On Mon, Jun 20, 2022 at 05:59:06AM +0000, Zhang, Chen wrote:
> > > >>
> > > >>
> > > >>> On Fri, Jun 17, 2022 at 03:36:19PM +0800, Zhang Chen wrote:
> > > >>>> Make iovisor/ubpf project be a git submodule for QEMU.
> > > >>>> It will auto clone ubpf project when configure QEMU.
> > > >>>
> > > >>> I don't think we need todo this. As it is brand new
> > > >>> functionality we don't have any back compat issues. We should
> > > >>> just expect the distros to ship ubpf if they want their QEMU builds to
> take advantage of it.
> > > >>>
> > > >>
> > > >> Yes, agree. It's the best way to use the uBPF project.
> > > >> But current status is distros(ubuntu, RHEL...) does not ship the
> > > >> iovisor/ubpf like the iovisor/bcc. So I have to do it.
> > > >> Or do you have any better suggestions?
> > > >
> > > > If distros want to support the functionality, they can add
> > > > packages for it IMHO.
> > >
> > > Yes, let's please avoid new submodules. Submodules can sometimes be
> > > a real PITA (e.g. if you forget to update before rsync'ing your code
> > > to a machine that has limited internet access), and if users install
> > > QEMU from sources, they can also install ubpf from sources, too.
> > > And if distros want to support this feature, they can package ubpf
> > > on their own, as Daniel said.
> >
> > Hi Daniel and Thomas,
> >
> > I don't know much the background history of QEMU submodules, but
> meson
> > build is a submodule for QEMU too. It means user can't install QEMU
> > from sources with limited internet access.
> > And back to Daniel's comments,  Yes, the best way is distros add the
> > ubpf packages, But maybe it's too late to implement new features for
> > us. We can introduce the submodule now and auto change to the distros's
> lib when distros add it.  For example QEMU's submodule SLIRP do it in the
> same way.
> > It's already added by most distros and still as a QEMU submodule. It
> > make user experience the latest technology with no other dependencies.
> > uBPF infrastructure have the ability to extend the capabilities
> > without requiring changing source code. If we not allow it, we have to re-
> implement all the eBPF assembler, disassembler, interpreter, and JIT
> compiler like DPDK userspace eBPF support (DPDK can't use ubpf project by
> license issue).
> 
> Slirp is a different scenario. That was functionality that was historically
> integrated into QEMU and was then spun out into a standalone project. Since
> we had existing users on existing distro releases dependant on Slirp, we
> wanted to give a smooth upgrade experiance by bundling Slirp. Essentially
> the goal was to avoid the regression if someone deployed new QEMU on
> existing distros.
> 
> Meson is a fairly similar scenario. We wanted to swap the build system in
> QEMU over to Meson, and that change would affect all existing users of
> QEMU.
> Many distros didn't have a new enough meson, and so bundling it in QEMU
> enables us to give a smooth upgrade path without any regression for existing
> users on existing distros.
> 
> This patch, however, is proposing an entirely new piece of functionality that
> has no existing users and even once present will be used by relatively few
> users compartively speaking. As such there is no upgrade compatibility /
> regression scenario that we need to worry about. Anyone interested in the
> new functionality can be reasonably asked to either wait for the distro to
> package it, or build it themselves.
> 

OK, got your point.
For this series, should we introduce an external library "libubpf" in QEMU 
configure?
If this library is found, the relevant files will be compiled and the feature 
can be enabled in QEMU.

Thanks
Chen

> With regards,
> Daniel
> --
> |: https://berrange.com      -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-
> https://www.instagram.com/dberrange :|