Re: [Qemu-devel] Future of SoftFloat use in QEMU

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

On Mon, May 08, 2017 at 03:58:59PM +0100, Alex Bennée wrote:
> Of course the softfloat in QEMU's tree hasn't been static either. We've
> made numerous changes over the years to add and fix various features,
> including features that have since been added to the upstream softfloat.

Based on way Peter achieved the switch to softfloat 2a, we can
reasonably identify the set of custom QEMU changes to the
original 2a code base.  From that diff, plus the subsequent
git history, it is within realm of practicality to at least
identify areas where we might need enhance/customize version 3.

> It seems unlikely we could switch to the newer softfloat without risking
> breaking something. However if we look at back-porting stuff from the
> newer library we essentially get to own our version of softfloat
> forever.

Maintaining our own fork forever certainly feels unappealing,
particularly with the big feature gap you identify for FP16

> So what else can we do?
> 
> We could investigate having both libraries included in QEMU. It seems
> the API has changed quite a bit so that might be possible although there
> would be hackage involved in having two different softfloat.h's
> involved.
> 
> This would be useful if we wanted to take a piecemeal approach to
> updating the library. For example we could just use softfloat3 when we
> need the newer features (e.g. FP16).
>
> Or we could convert one architecture at a time so each qemu binary links
> against either a version 2 or version 3 softfloat library. Of course
> that does run the risk of permanently holding two versions of softfloat
> in the code if the less maintained guest architectures don't convert
> quickly.
> 
> So any thoughts about what would make the best approach?

WRT to supporting the FP16 feature, I'd certainly vote for using softfloat3,
over trying to re-implement FP16 ourselves in the old codebase we have a fork
of, even if that means us carrying both versions forever (provided having
both versions present in QEMU doesn't cause us symbol clashes ?).

Incrementally converting existing usage to softfloat3 is reasonable, but
doesn't seem like a decision that needs to be an immediate blocker for
FP16 usage. Given our desire to kill off areas of code which are not actively
maintained, it could be reasonable to set a timebox on softfloat3 conversion
for architectures eg must be completed within 3 release cycles, or we'll
consider the architecture unmaintained and subject for removal.

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 :|