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

[Marc-André Lureau]

Hi

On Tue, Oct 15, 2019 at 10:48 AM Daniel P. Berrangé <address@hidden> 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
> > >> <address@hidden> 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).

libslirp will take even longer.