Messages in this thread |  | | Date | Wed, 4 Dec 2013 11:33:25 +0000 | From | Stefano Stabellini <> | Subject | Re: [Xen-devel] [PATCH RFC] xen-block: correctly define structures in public headers |
| |
On Wed, 4 Dec 2013, Stefano Stabellini wrote: > On Tue, 3 Dec 2013, Konrad Rzeszutek Wilk wrote: > > > > If Konrad and Boris agree that breaking the kernel's ABI in this way is > > > > acceptable in this specific case, I'll defer to them. > > > > > > My opinion as Xen on ARM hypervisor maintainer is that this is the right > > > thing to do in this case. > > > > Heh. If somebody can guarantee me that (by testing the right variants and > > mentioning this in the git commit) that this does not break x86, then > > I am fine. > > > > And by 'break x86' I mean that this combination works: > > 32-bit domU on 64-bit dom0 > > 64-bit domU on 32-bit dom0 > > > > And perhaps also the obvious: > > 64-bit domU on 64-bit dom0 > > 32-bit domU on 32-bit dom0 > > > > Since the xen-blkback has its own version of the structs there is no > > need to change change newer and older version of it. > > > > As long as that works I am OK sticking it in. > > > > I think from the ARM perspective it is still in 'experimental' phase > > so anything goes to make it work under ARM. > > To be honest I am unhappy about this, but I don't want to clutter even > more a code path already plagued by an ifdef infestation. > > Even if the ARM port is experimental, I would prefer to retain > compatibility if it was possible to do so with a couple of lines fix. > Otherwise I would rather break ABI compatibility than introducing > another half a dozen ifdefs.
Let me rephrase this as it can be misinterpreted as a NACK for this patch while it is not.
I would like not to break existing ARM guests. However we do need to fix this and I can't see a decent way to do so retaining compatibility with the broken interface that we are currently implementing. Therefore I am OK with the patch.
|  |