[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] qemu-traditional: Bump piix4acpi save-record version_id



Andrew Cooper writes ("Re: [PATCH] qemu-traditional: Bump piix4acpi save-record 
version_id"):
> On 16/12/2013 16:23, Ian Jackson wrote:
> > And in practice I don't foresee us wanting to bump our own format any
> > time soon.  qemu-xen-traditional is in the deep freeze
> > maintenance-wise.
> 
> By "break", I mean "require some more cunning solution to the problem to
> be found".  It will certainly not be subtle in terms of merge conflicts.
> 
> If upstream were to introduce a new v3 record with a different format,
> XenServer's fix would have to automatically bump up to v4, and extend
> the detection logic.  The amount of hacking would have to increase every
> time upstream changed.

I think it very unlikely that qemu-xen-traditional will grow an
entirely new format at this stage of its life.

But if it did, I think all of this would be a SMOP.  And not even a
particularly difficult one: the difference would be just in the
version numbers.

> I refer you to
> https://github.com/xenserver/xen-4.3.pg/blob/master/xen-legacy-win-xenmapspace-quirks.patch
> which shows the amount of hackary required when it is not possible to
> take a preemtive step like this to prevent it breaking in the future.

Firstly, a situation like that isn't going to arise I think.

Secondly: it is right that the XenServer project, not other users of
Xen, bears the cost of the technical debt incurred by previous
XenServer maintainers.

> I guess this all comes down to how likely the piix4acpi object version
> id is to change in the future.  It is certainly possible for me to fix
> this in XenServer only, and might be the better way if it is fairly
> certain that none of this is going to change in qemu-traditional going
> forward.

Frankly I think it unlikely that this code is going to be touched
again ever.  If it does it will be as part of an attempt to make it
compatible with XenServer.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.