[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH, RFC 0/5] Improve device info handling
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] [PATCH, RFC 0/5] Improve device info handling |
Date: |
Tue, 1 Sep 2009 19:21:42 +0300 |
On Tue, Sep 1, 2009 at 10:54 AM, Gerd Hoffmann<address@hidden> wrote:
> On 08/31/09 17:23, Blue Swirl wrote:
>>
>> On Mon, Aug 31, 2009 at 11:12 AM, Gerd Hoffmann<address@hidden> 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)?