| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH] tmem (tools-side): ABI v1 to handle long object-
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