Re: [Qemu-devel] What to do about non-qdevified devices?

[Andreas Färber]

Am 30.01.2013 13:35, schrieb Markus Armbruster:
> Peter Maydell <address@hidden> writes:
> 
>> On 30 January 2013 07:02, Markus Armbruster <address@hidden> wrote:
>>> Anthony Liguori <address@hidden> writes:
>>>
>>> [...]
>>>> The problems I ran into were (1) this is a lot of work (2) it basically
>>>> requires that all bus children have been qdev/QOM-ified.  Even with
>>>> something like the ISA bus which is where I started, quite a few devices
>>>> were not qdevified still.
>>>
>>> So what's the plan to complete the qdevification job?  Lay really low
>>> and quietly hope the problem goes away?  We've tried that for about
>>> three years, doesn't seem to work.
>>
>> Do we have a list of not-yet-qdevified devices? Maybe we need to
>> start saying "fix X Y and Z or platform P is dropped from the next
>> release". (This would of course be easier if we had a way to let users
>> know that platform P was in danger...)
> 
> I think that's a good idea.  Only problem is identifying pre-qdev
> devices in the code requires code inspection (grep won't do, I'm
> afraid).

+1 That would address my request as well.

Having a list of low-hanging fruit on the Wiki might also give new
contributors some ideas of where and how to start poking at the code.

> If we agree on a "qdevify or else" plan, I'd be prepared to help with
> the digging up of devices.

I disagree on the "or else" part. I have been qdev'ifying and QOM'ifying
devices in my maintenance area, and progress is slow. It gets even
slower if one leaves clearly maintained areas. I see no good reason to
force a pistol on someone's breast, like you have done for IDE, unless
there is a good reason to do so. Currently I don't see any.

Just think of my pending ide/mmio.c patch [1] that no one has reviewed
or applied so far. Similarly, Fred's virtio refactoring has pretty long
review cycles, with discussions about very basic QOM and OOD idioms.

If we want to make progress, we need to encourage contributors to send
such patches by making sure they get feedback and find their way into
the tree within a reasonable time frame. It's always easier to rip out
and damage other people's work than to get things right yourself.

To take that thought to the extreme, I could propose to rip out any qdev
device that's not properly QOM'ified and realize'ified yet. That would
include i440fx, fdc and many core x86 devices in the repository...

Technical risks have been raised elsewhere: Making random code
SysBusDevices can lead to PCIDevices instantiating them not being
hot-pluggable any more simply because SysBus is a crappy fallback,
overused in lack of a clear alternative. I already started reviewing
parent_bus and qdev_get_parent_bus() uses in the tree [2, 3], but
constructive help would be more welcome than constant nagging about code
that's in bad shape. There's a lot of work to be done!

Andreas

[1] http://patchwork.ozlabs.org/patch/215482/
[2] http://patchwork.ozlabs.org/patch/209499/
[3] http://patchwork.ozlabs.org/patch/213971/

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg