Re: RFC: Why dont we move to newer capstone?

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Oct 15, 2019 at 11:02:43AM +0200, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Oct 15, 2019 at 10:48 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Tue, Oct 15, 2019 at 10:36:40AM +0200, Thomas Huth wrote:
> > > On 15/10/2019 10.27, Daniel P. Berrangé wrote:
> > > > On Sat, Oct 05, 2019 at 02:33:34PM +0100, Peter Maydell wrote:
> > > >> On Sat, 5 Oct 2019 at 11:21, Lucien Murray-Pitts
> > > >> <lucienmp.qemu@gmail.com> wrote:
> > > >>> Whilst working on a m68k patch I noticed that the capstone in use
> > > >>> today (3.0) doesnt support the M68K and thus a hand turned disasm
> > > >>> function is used.
> > > >>>
> > > >>> The newer capstone (5.0) appears to support a few more CPU, inc. m68k.
> > > >>>
> > > >>> Why we move to this newer capstone?
> > > >>
> > > >> Moving to a newer capstone sounds like a good idea. The only
> > > >> reason we haven't moved forward as far as I'm aware is that
> > > >> nobody has done the work to send a patch to do that move
> > > >> forward to the newer version. Richard Henderson would
> > > >> probably know if there was any other blocker.
> > > >
> > > > Bearing in mind our distro support policy, we need to continue to
> > > > support 3.0 series of capstone for a while yet based on what I
> > > > see in various distros. eg Ubuntu 18.04 LTS has 3.0.4, as does
> > > > Fedora 29.  Version 4.0 is only in a few very new distros:
> > > >
> > > >    https://repology.org/project/capstone/versions
> > > >
> > > > We can of course use features from newer capstone, *provided* we correctly
> > > > do conditional compilation so that we can still build against 3.0 series
> > > > on distros that have that version.
> > >
> > > We're embedding the capstone submodule in the release tarballs, so I
> > > think we're independent from the distro release, aren't we? So this
> > > should not be an issue, as far as I can see.
> >
> > It is an issue for people/distros who don't want to building with bundled
> > 3rd party code.
> >
> > I'd suggest it is probably time we could drop the capstone git submodule.
> > We originally added it because capstone wasn't widely present in distros
> > we care about. AFAICT, it is now present in all the distros, so could be
> > treated the same way as any other 3rd party library dep we have.
> 
> I suppose the same applies to dtc (1.4.2 required by qemu, but xenial
> has 1.4.0... so we have to wait until April 26, 2020? 18.04 LTS
> release date + 2y).

Possibly - depends on scope of changes between 1.4.0 & 1.4.2 - maybe it
is easy to conditionally support 1.4.0 too.

> libslirp will take even longer.

This is reasonable as a git submodule for a while yet, since it only
existed as a separate project very recently, so isn't widely available
across distros / OS.

IMHO the key point is that submodules bundling 3rd party libraries [1]
should be viewed as something with a limited lifetime. A temporary
hack until distros have the library widely available, rather than
something which continues forever.

Regards,
Daniel

[1] We have other types of submodule.

    The keycodemapdb which is not a library, rather a static database
    from which we auto-generate code to statically link in.

    The firmware submodules which developers don't actually build from
    normally. Ideally these would go into a separate dist tarball but
    we seem stalled on this idea despite discussing it many times.
-- 
|: 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 :|