Re: [Qemu-devel] [PATCH, RFC 0/5] Improve device info handling

[Blue Swirl <blauwirbel@gmail.com>]

On Tue, Sep 1, 2009 at 10:54 AM, Gerd Hoffmann<kraxel@redhat.com> wrote:
> On 08/31/09 17:23, Blue Swirl wrote:
>>
>> On Mon, Aug 31, 2009 at 11:12 AM, Gerd Hoffmann<kraxel@redhat.com>  wrote:
>>>
>>>  Hi,
>>>
>>>> Add info command registration to the API and make some devices use it.
>>>
>>> Jumping in here with a more general comment ...
>>>
>>> I think right now we have _way_ to much register_something functions.
>>> IMHO qdev allows us to kill off most of them.  We can stick function
>>> pointers (also VMstate pointers) into DeviceInfo instead of registering
>>> callbacks.
>>
>> Good idea. I wish reset could be handled also with a structure.
>
> reset is easy.  I'll send out a patch series shortly to make more clear what
> I'm talking about.
>
>>> Short-term (while we are in the "convert-drivers-to-qdev" phase) that
>>> will
>>> just move the register calls from the driver code to generic qdev code.
>>>
>>> Long-term we hopefully can kill the register calls altogether and walk
>>> the
>>> qdev device tree instead.
>>
>> So at this stage, the registration function should take a structure
>> argument but later it would be sucked into qdev?
>
> Now: registration moves from drivers to qdev.c
> Later: no registration needed any more, all info needed is in the qdev
> device tree.
>
>>> Hmm, i8259 isn't converted to qdev yet, so the route outlined above above
>>> will not work (yet) for this device ...
>>
>> There is also no qdev for pc.c. Maybe there should be one qdev for
>> each board? The higher level could set up common things like system
>> reset signal, memory, drives etc. Maybe even PCI.
>
> IIRC openfirmware has one (or more?) device tree entries for memory, so this
> fits nicely into qdev.  Not sure how to handle that best for pc ...
>
> drives are host side state, they don't go into qdev.

My idea was that boards (like pc) should be in the long run
represented by a qdev. The higher level metamachine would instantiate
the "pc" qdev and plug in drives, memory, reset, power button, PCI
devices etc. Something like:

    DeviceState *dev;
    BoardDevice *s;

    dev = qdev_create(NULL, "pc");
    qdev_init(dev);
    s = board_from_qdev(dev);

    board_add_cpus(s, smp_cpus);
    board_add_memory(s, RAM_size);
    board_add_network(s, nd_tables[0]);
    board_add_block(s, drives_table[0]);
    board_add_serial(s, serial_hds[0]);
    board_add_display(s, ds); // DisplayState *

But shouldn't the drives, network and char devices be qdevs too,
wouldn't it help the metamachine (or "pc" device)?