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

[Gerd Hoffmann <kraxel@redhat.com>]

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.

Speaking of qdev:  You seem to be reluctant committing qdev patches 
(except obviously correct one-liners), which is quite understandable as 
qdev is done by Paul.  Problem is that there are lots of qdev patches on 
the list from me and others which are largely ignored.  Some of my 
patches got committed.  Fine.  Some got comments from Paul.  Fine too, 
so I know why they are not committed and can work on the issues.  Most 
of my patches are ignored.  Hmm.  How to go forward here?  I suspect 
reposting over and over wouldn't help here.

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.  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).
   (2) Depending on (1): How will we handle attributes?  Read/write
       directly from/to the fdt?  Keep them in qdev data structures?

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

cheers,
   Gerd