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-

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] tmem (tools-side): ABI v1 to handle long object-ids (XEN-UNSTABLE)
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 3 Sep 2010 12:45:38 -0700 (PDT)
Cc: "Xen-Devel \(xen-devel@xxxxxxxxxxxxxxxxxxx\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Fri, 03 Sep 2010 12:48:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19585.13664.314624.384087@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <b9b13d56-0bbc-4ea2-b8e8-ab1dbcdd521c@default 19585.13664.314624.384087@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

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