qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC 00/10] pci: Partial conversion to realize


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH RFC 00/10] pci: Partial conversion to realize
Date: Mon, 03 Nov 2014 08:22:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

"Michael S. Tsirkin" <address@hidden> writes:

> On Tue, Oct 28, 2014 at 08:35:29AM +0100, Markus Armbruster wrote:
>> While discussing Gonglei's "[PATCH v2 00/19] usb: convert device init
>> to realize", Paolo called the PCI conversion job "Gargantuan".  This
>> series attempts to crack it into manageable jobs.
>> 
>> The basic idea comes from qdev core: have the core deal with just
>> realize, but default the device models' realize() method to one that
>> calls the old init() method.  Unconverted device models don't set
>> their realize(), thus get one that calls their init().  We can then
>> convert device by device instead of having to convert of all of PCI in
>> one Gargantuan go.
>> 
>> Since PCI's exit() cannot fail, I chose not to add an unrealize().
>> Precedence: USBDeviceClass method handle_destroy(), called on USB
>> unrealize.
>> 
>> Aside: USBDeviceClass also has an unrealize() method, but it's never
>> set and never called.
>> 
>> PATCH 01 converts the interface between PCI core and qdev to realize.
>> 
>> PATCH 02 adds realize to the interface between PCI core and PCI device
>> models.  Once all device models are converted to realize, the old init
>> interface can be dropped, completing the Gargantuan job.
>> 
>> PATCH 03-04 convert device models that cannot fail initialization.
>> 
>> PATCH 05-10 convert a few that can fail, but are really easy to
>> convert.
>> 
>> This series is RFC because it's based on Marcel's "[PATCH v2] hw/pci:
>> fixed crash when using rombar=0 with romfile=path for hotplugged
>> devices", which is still undergoing review.
>
> I've applied that one, and your patchset looks good to me,
> But of course we can't apply new refactorings right now after soft
> freeze.  Unless this fixes some bug?

I'm okay with delaying my series some.  I'd appreciate a ping when
you're ready to accept "for 2.3" patches into your tree.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]