For the record, I've figured out a way on the Linux-side
tmem patch to support backwards compatibility to tmem v0.
Guests with this patch will work for Xen tmem v0 and tmem v1.
It's ugly enough that I won't be proposing it upstream but
simple enough that it's a reasonable patch for Linux distros
that support tmem, e.g. to be backwards compatible with
Xen 4.0.0 and/or other Xen distros that have shipped with
tmem v0. Vice-versa won't be supported however (e.g.
tmem v0 guests on tmem v1 Xen) but, if necessary, that is
resolvable with a simple in-guest kernel upgrade.
Also, migrating of running tmem guests between Xen hosts
with different tmem versions will not be supported.
> -----Original Message-----
> From: Dan Magenheimer
> Sent: Friday, September 03, 2010 1:46 PM
> To: Ian Jackson
> Cc: Xen-Devel (xen-devel@xxxxxxxxxxxxxxxxxxx); Keir Fraser
> Subject: RE: [Xen-devel] [PATCH] tmem (tools-side): ABI v1 to handle
> long object-ids (XEN-UNSTABLE)
>
> Hi Ian --
>
> > From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
> >
> > Dan Magenheimer writes ("[Xen-devel] [PATCH] tmem (tools-side): ABI
> v1
> > to handle long object-ids (XEN-UNSTABLE)"):
> > > tmem (tools-side): move to new ABI version to handle
> > > long object-ids
> >
> > Thanks for this patch.
> >
> > I'm sad to say that this appears to confirm that the decision by the
> > world in general not to use tmem yet was correct. After all if they
> > _were_ using it now they'd have some pain.
>
> 1) To be fair, I've never yet advertised tmem as anything but
> experimental or "technology preview". But if tmem WAS widely
> deployed today, backwards compatibility was certainly possible,
> just a pain (for me and for Xen code maintainability) that,
> since it was not widely deployed, I chose to avoid.
>
> 2) As one wag put it, that's the risk one takes when releasing
> a technology before it is accepted mainstream in "the kernel".
> Tmem requires some coordination between Linux and Xen so
> the tmem ABI was designed to be extremely flexible and this was
> the first time in >18 months that an ABI rev was "necessary".
>
> 3) The problem that resulted in the ABI change could have fairly
> easily been handled on the Linux side*, but would have required
> changes to multiple filesystems. As other Xen developers have
> discovered, tails don't easily wag dogs and (to mix metaphors)
> that was a rathole I chose not to explore. (* One would think
> that 64 bits would be sufficient to uniquely represent a file
> in a filesystem :-)
>
> > I don't have a strong opinion about this patch. The tools part seems
> > reasonably well-contained so I guess I'm happy to see it applied.
>
> Thanks. All of tmem was designed to be well-contained with very little
> impact on other subsystems. I was pleased that a rather major
> change like this had as low impact as it did on libxc.
>
> > > Please apply to XEN-UNSTABLE ... see separate post for
> > > the essentially identical xen-4.0-testing equivalent.
> >
> > It would probably be best if Keir applied both patches in a single
> > changeset, to avoid build breakage.
>
> However the two of you want to arrange it is OK with me as
> long as both patches are applied temporally relatively near.
> (And preferably both for both 4.0-testing and xen-unstable.)
>
> > It would be easier to find your messages if your patchbomb script (or
> > your mailer, if you're doing it by hand) could be persuaded to post
> > all the portions of a series in a single thread, with appropriate
> > In-Reply-To and References headers.
>
> This is the first patch I've submitted since Keir's request
> for tools patches to go to you, and the first patch in a LONG
> time that crossed the boundary between hypervisor and tools.
> I can submit tmem patches however you like... I was just using
> the same process Keir has cheerfully accepted in the past
> (and tried to split tools from hypervisor as best I could...
> in the past, a monolithic patch was sufficient since there was
> little interest in reviewing details of tmem-related patches
> anyway).
>
> Sheepishly, I admit I use Outlook for most mundane email tasks
> including Xen patches but can (and have, for lkml) submitted patch
> series via a Linux mailer.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home