On Thu, Jul 13, 2017 at 04:34:28PM +0100, Daniel P. Berrange wrote: > On Thu, Jul 13, 2017 at 05:18:24PM +0200, Christophe Fergeau wrote: > > On Thu, Jul 13, 2017 at 02:39:19PM +0200, Guido Günther wrote: > > > On Wed, Jul 12, 2017 at 09:35:16AM +0200, Christophe Fergeau wrote: > > > > > > > > However for this one I'd expect arch = "armv7l" as this is what is in > > > > the RNG schema? My understanding of > > > > https://bugzilla.redhat.com/show_bug.cgi?id=719609#c13 is that armv7l is > > > > a soft floating point arch, armv7hl would be hard floating point. And > > > > > > > > > > > > > armhf is hard floating point as well. So I don't think we can consider > > > > the 2 are the same here. You probably need to add a new ARM arch to the > > > > schema file, and use that for armhf. > > > > > > On my A20 Olinuxino I see > > > > > > $ uname -m > > > armv7l > > > > > > $ dpkg --print-architecture > > > armhf > > > > > > I assumed that the armv7l refers to an architecture supporting hard > > > float but your link suggests otherwise. In this case we need to fixup > > > osinfo-db as well. I couldn't find any other good references on this. > > > > > > > Oh well, I'm utterly confused by ARM arch names, so maybe armv7l and > > armhf are the same, I would not know :( > > So the architecture is basically "arm7" and QEMU emulates an 'arm7' > architecture. > > hard float vs soft float is essentially referring to how the guest > software and kernel is compiled - whether it was built to use software > emulated floating point vs hardware floating point. > > So as long as you tell QEMU to emulate a CPU model for arm7 that can > do hard float, then QEMU can support guests OS which use hard or soft > float. > > This is a long winded way of saying that in terms of representing > architectures in libvirt and libosinfo, we don't need a distinction > between hard & soft float arm. They're all just arm7. > > The distinction is more akin having an i686 guest, which is compiled > to assume a CPU model with SSE instructions. This is a concept we > don't track in libosinfo right now. We could, but I'd just ignore > until its critical (if ever). Yup, makes a lot of sense, thanks for the detailed explanation! Christophe
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
