Re: [Qemu-devel] sending pci information over the wire

[Anthony Liguori]

Gerd Hoffmann wrote:
> On 06/18/09 22:38, Anthony Liguori wrote:
> > Glauber Costa wrote:
> > > Sure.
> > >
> > > Question is, whether or not there is any value in doing this now.
>
> Prototyping, playing with it, figure any roadblocks: yes.
> Merging: no.
>
> I think we should go for the "big" solution, i.e. machine-config for 
> *everything*, not just PCI.  The move from the current model to the 
> machine-config based one will be difficuilt enougth, we should not 
> make it even harder to support by merging a half-done interim solution.
>
> > We're really close to a machine config for pc though, I'm not sure that
> > that's not a quicker solution.
>
> Well, we are not *that* close.
>
> Paul Brooks fdt works fine for some simple embedded boards.  To make 
> it fly with pc a noticable amount of work is needed (I'm working on 
> that ;).  Partly that is a simple conversion of drivers to qdev.  
> Partly that involves reorganization and cleanup of drivers and 
> subsystems and the dependencies they have.  Which certainly is a good 
> thing because it cleans up the code.  But it needs to be done before 
> machine-config can work for pc.

I've been considering queue all patches on the list to keep track of 
which ones don't get applied.  The problem is, something like your qdev 
series really needs to be applied quickly because it conflicts with 
quite a lot of other patches.

My plan for your qdev series is to give a little more time for feedback, 
then ask you to rebase/resubmit so they can be applied.  Give it a 
couple more days to give people a chance to review.

> Likewise devtree:  Paul posted the patches, got a number of reviews 
> comments.  No discussion of the concerns happened though.  There is 
> also no activity in Pauls git tree.

I think we're all just waiting for Paul to commit something.

>   There are some quite fundamental design issues which need to be 
> decided:
>
>   (1) How will we handle fdt and hotplug?  We can keep the qdev tree
>       and the fdt in sync all the time.  Or we generate a fresh fdt
>       from the qdev tree when needed (i.e. for savevm, migration and
>       maybe the ppc kernel).

I'd lean toward the later.

>   (2) Depending on (1): How will we handle attributes?  Read/write
>       directly from/to the fdt?  Keep them in qdev data structures?

I think qdev is the master tree and fdt just becomes a conversion format.

> I really like to see some progress here, otherwise 2017 wouldn't be 
> just a running gag.

I agree.  Not every patch is reasonable to commit in 24 hours though.  
Some require giving people appropriate time to review.  I think 
something we could do better is avoiding losing track of patches 
though.  I'm working on that.

Regards,

Anthony Liguori

> cheers,
>   Gerd