This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] [PATCH] tmem (tools-side): ABI v1 to handle long object-

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

<Prev in Thread] Current Thread [Next in Thread>