| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: save/restore dev in HV
now, it's clear for me.
thanks,
On Mon, Jan 22, 2007 at 08:46:37AM +0000, Keir Fraser wrote:
> On 22/1/07 2:44 am, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx> wrote:
>
> > 1. it put more responsibility on developer to maintain the format/alignment
> > of
> > hw status struct.
>
> This is true. We now have anough script support for CONFIG_COMPAT that we
> could probably check all save structs for 32-on-64 compatibility
> automatically.
>
> > 2. compatibility issue. e.g. adding a new field in middle of the hw struct
> > would break restoring an old image.
>
> We wouldn't do this -- we'd define a new structure, or add new fields at the
> end in a backward compatible way.
>
> The code as it is is *not* finished by the way, and so gives a slightly poor
> impression of this approach. The aim is to have some of the structures
> broken down into more chunks: so for example the hvm_irq structure will move
> back to where it came from (a private header file) and instead we will have
> descriptor chunks for PCI INTx wire state, ISA IRQ wire state, and PCI-ISA
> link state -- note that each of these will effectively be an array which
> will be easily extended (or shrunk) if e.g., we add another PCI bus.
>
> This is the hard bit -- auditing every chunk, deciding if it contains
> redundant info, or info that is only an artefact of the crrent device-model
> implementation, or whether the chunk needs to be broken into more pieces to
> maintain better logical grouping and extensibility.
>
> -- Keir
>
--
best rgds,
edwin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home