Re: [Xen-devel] [PATCH 10/27] docs: Libxl migration v2 stream specification

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 16/06/2015 14:58, Ian Campbell wrote:
> On Mon, 2015-06-15 at 14:44 +0100, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> +EMULATOR\_CONTEXT
>> +----------------
>> +
>> +A context blob for a specific emulator associated with the domain.
>> +
>> +     0     1     2     3     4     5     6     7 octet
>> +    +------------------------+------------------------+
>> +    | emulator_id            | index                  |
>> +    +------------------------+------------------------+
>> +    | emulator_ctx                                    |
>> +    ...
>> +    +-------------------------------------------------+
>> +
>> +--------------------------------------------------------------------
>> +Field            Description
>> +------------     ---------------------------------------------------
>> +emulator_id      0x00000000: Unknown (In the case of a legacy stream)
>> +
>> +                 0x00000001: Qemu Traditional
>> +
>> +                 0x00000002: Qemu Upstream
>> +
>> +                 0x00000003 - 0xFFFFFFFF: Reserved for future emulators.
> Would it be useful for future proofing to carve out some space for a
> per-emulator version field too?

What would that be useful for?  It is the emulators problem/fault if it
can't read the blob it is given.

Superficially, I can see why the field would be nice for debugging
purposes, but not all emulators will have a consistent version scheme,
and we only install a single version of each emulator.  All I can see
happening is libxl starting to guess about emulator/blob compatibility,
which is absolutely not its place to do.

>
> Otherwise LGTM.
>
> One thought, it might be useful (here or elsewhere) to have an explicit
> overview of the expected control flow (as in the ownership of the fd,
> and/or nesting of the layers as you prefer to think about it) between
> libxc, libxl and the next layer (i.e. xl).

I will see what I can do, but the freeze is very imminent.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel