From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>,
Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH v3 18/28] tools/libxl: Infrastructure to convert a legacy stream
Date: Mon, 13 Jul 2015 16:53:30 +0100 [thread overview]
Message-ID: <55A3DEFA.1020303@citrix.com> (raw)
In-Reply-To: <21923.56522.314560.338503@mariner.uk.xensource.com>
On 13/07/15 16:44, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH v3 18/28] tools/libxl: Infrastructure to convert a legacy stream"):
>> On 13/07/15 15:45, Ian Jackson wrote:
> ...
>>> I'm afraid I don't understand why this script needs to be told the
>>> toolstack build bit width. (If indeed the toolstack build bit width
>>> is the right thing, can't the script tell what bitness it is running
>>> on, some other way?)
>> The script needs to know the bitness of the toolstack which saved the
>> legacy stream, not the bitness of the one which is currently running.
> But an ifdef tells you the bitness of the toolstack which is currently
> running.
>
>> The ifdefary above is an assumption for the common case. By
>> observation, noone outside of XenServer has tried migrating a VM from a
>> 32bit toolstack to a 64bit, or they have and not reported a bug.
>> Therefore, the common case is that the bitness of toolstack is the same.
> I see.
>
>> If in the future someone genuinely needs to convert legacy -> v2 and 32
>> -> 64bit at the same time, they can use the conversion script manually
>> to achieve this (even in a migration), which will bypass the conversion
>> logic in libxl, as the incoming stream is already v2.
> How ... exciting.
>
>>> I appreciate that this seems very pernickety for compatibility code
>>> which will only be executed on i386 or amd64, but #ifdefs like this
>>> make the code hard to read IMO.
>> Would it be acceptable to format the above description into a comment?
> That would help.
>
> But also I want rid of the #ifdef for stylistic reasons.
>
> How about you make the --width option optional, and default it to
> native bitness in the conversion script ?
I could do, but that would make the further assumption that the width of
libxl is the same as the width of python, which is by no means
guaranteed to be the case.
I could see about doing something based on BITS_PER_LONG which doesn't
have a visible ifdef, but is still ifdefary.
~Andrew
next prev parent reply other threads:[~2015-07-13 15:53 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-13 12:01 [PATCH v3 00/27] Libxl migration v2 Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 01/28] bsd-sys-queue-h-seddery: Massage `offsetof' Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 02/28] tools/libxc: Always compile the compat qemu variables into xc_sr_context Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 03/28] tools/libxl: Introduce ROUNDUP() Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 04/28] tools/libxl: Introduce libxl__kill() Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 05/28] tools/libxl: Stash all restore parameters in domain_create_state Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 06/28] tools/libxl: Split libxl__domain_create_state.restore_fd in two Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 07/28] tools/libxl: Extra management APIs for the save helper Andrew Cooper
2015-07-13 13:21 ` Ian Campbell
2015-07-13 15:01 ` Ian Jackson
2015-07-13 12:01 ` [PATCH v3 08/28] tools/libxl: Add save_helper_state pointers to libxl__xc_domain_{save, restore}() Andrew Cooper
2015-07-13 13:24 ` Ian Campbell
2015-07-13 12:01 ` [PATCH v3 09/28] tools/xl: Mandatory flag indicating the format of the migration stream Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 10/28] docs: Libxl migration v2 stream specification Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 11/28] tools/python: Libxc migration v2 infrastructure Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 12/28] tools/python: Libxl " Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 13/28] tools/python: Other migration infrastructure Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 14/28] tools/python: Verification utility for v2 stream spec compliance Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 15/28] tools/python: Conversion utility for legacy migration streams Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 16/28] tools/libxl: Migration v2 stream format Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 17/28] tools/libxl: Infrastructure for reading a libxl migration v2 stream Andrew Cooper
2015-07-13 13:42 ` Ian Campbell
2015-07-13 13:53 ` Andrew Cooper
2015-07-13 14:11 ` Ian Jackson
2015-07-13 14:03 ` Ian Jackson
2015-07-13 14:31 ` Ian Jackson
2015-07-13 14:53 ` Andrew Cooper
2015-07-13 15:33 ` Ian Jackson
2015-07-13 15:08 ` Ian Jackson
2015-07-13 15:13 ` Andrew Cooper
2015-07-13 15:35 ` Ian Jackson
2015-07-13 12:01 ` [PATCH v3 18/28] tools/libxl: Infrastructure to convert a legacy stream Andrew Cooper
2015-07-13 14:45 ` Ian Jackson
2015-07-13 15:08 ` Andrew Cooper
2015-07-13 15:44 ` Ian Jackson
2015-07-13 15:53 ` Andrew Cooper [this message]
2015-07-13 15:56 ` Ian Jackson
2015-07-13 16:04 ` Ian Campbell
2015-07-13 12:01 ` [PATCH v3 19/28] tools/libxl: Convert a legacy stream if needed Andrew Cooper
2015-07-13 14:51 ` Ian Jackson
2015-07-13 15:20 ` Andrew Cooper
2015-07-13 15:44 ` Ian Jackson
2015-07-13 12:01 ` [PATCH v3 20/28] tools/libxc+libxl+xl: Restore v2 streams Andrew Cooper
2015-07-13 15:02 ` Ian Jackson
2015-07-13 12:01 ` [PATCH v3 21/28] tools/libxl: Infrastructure for writing a v2 stream Andrew Cooper
2015-07-13 15:09 ` Ian Jackson
2015-07-13 15:21 ` Ian Jackson
2015-07-13 15:33 ` Andrew Cooper
2015-07-13 15:47 ` Ian Jackson
2015-07-13 15:56 ` Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 22/28] tools/libxc+libxl+xl: Save v2 streams Andrew Cooper
2015-07-13 15:25 ` Ian Jackson
2015-07-13 12:01 ` [PATCH v3 23/28] docs/libxl: Introduce CHECKPOINT_END to support migration v2 remus streams Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 24/28] tools/libxl: Write checkpoint records into the stream Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 25/28] tools/libx{c, l}: Introduce restore_callbacks.checkpoint() Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 26/28] tools/libxl: Handle checkpoint records in a libxl migration v2 stream Andrew Cooper
2015-07-13 13:53 ` Ian Campbell
2015-07-14 10:33 ` Yang Hongyang
2015-07-14 10:35 ` Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 27/28] tools/libxc: Drop all XG_LIBXL_HVM_COMPAT code from libxc Andrew Cooper
2015-07-13 12:01 ` [PATCH v3 28/28] tools/libxl: Drop all knowledge of toolstack callbacks Andrew Cooper
2015-07-13 15:55 ` Ian Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55A3DEFA.1020303@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.