Re: RFC qdev path semantics

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/16/2010 04:46 AM, Markus Armbruster wrote:
> A number of changes to qdev paths have been proposed in various threads.
> It's becoming harder to keep track of them, so let me sum them up in one
> place.  Please correct me if I misrepresent your ideas.
>    

Honestly, I think we've gone off the deep end here.  Let's simplify.

We need to uniquely identify ram allocations for the purposes of 
savevm.  Let's do this:

qdev has a vmsd property.  When the qdev device is initialized, it 
invokes vmstate_register_with_alias_id.

Let's have vmstate_register_with_alias_id return a unique identifier.  
Today, it should be derived from the section header.  In the future, it 
should be a qdev path (as should the section header).

We need have a qdev->vmsd_base.  pci_add_option_rom() will pass 
qdev->vmsd_base + a unique suffix to qemu_ram_alloc() which should be in 
the form '/suffix'.  This suffix only need to identify the ram area 
uniquely for for pci_add_option_rom, it should probably be '/PCI-ROM'.

Today, this means that the ram allocations will be consistent with 
VMState which is a good thing on the wire.  In the future, when we have 
full qdev conversion, we can easily switch to using qdev paths as the 
vmsd_base with almost no code change.

Regards,

Anthony Liguori