[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.