Re: What to do about non-qdevified devices?

[Markus Armbruster <armbru@redhat.com>]

Andreas Färber <afaerber@suse.de> writes:

> Am 30.01.2013 13:35, schrieb Markus Armbruster:
>> Peter Maydell <peter.maydell@linaro.org> writes:
>> 
>>> On 30 January 2013 07:02, Markus Armbruster <armbru@redhat.com> wrote:
>>>> Anthony Liguori <aliguori@us.ibm.com> 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

Good work, much appreciated.

> 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.

There's the reason that made me hijack this thread.  Paraphrashing
Anthony: doing IRQs right involves Pin objects, and ultimately requires
all bus children have been qdevified.  Even for ISA, there are still
stragglers holding us back.

Is that sufficient reason to rip out devices *now*?  No, and I didn't
call for it.

Could it become sufficient reason in the not too distant future?
Possibly.  Should we plan ahead for such a contingency?  Probably.  But
I didn't call for that either.

What I actually wrote was 1. I think mapping the remaining qdevification
work is a good idea, and 2. if we commit to attempt doing that work in a
reasonable time frame, I'd be willing to help with the mapping.
Implying that without such a committment, sorry, got more immediately
useful things to do.

And by the way, the kind of "pistol" I get to brandish in this group is
about as scary as a water pistol in the middle of the Gobi desert.

[...]