Re: [PULL 00/10] Modules 20200702 patches

[Paolo Bonzini <pbonzini@redhat.com>]

On 03/07/20 12:39, Gerd Hoffmann wrote:
> On Fri, Jul 03, 2020 at 09:54:13AM +0100, Peter Maydell wrote:
>> On Thu, 2 Jul 2020 at 13:23, Gerd Hoffmann <kraxel@redhat.com> wrote:
>>>
>>> The following changes since commit fc1bff958998910ec8d25db86cd2f53ff125f7ab:
>>>
>>>   hw/misc/pca9552: Add missing TypeInfo::class_size field (2020-06-29 21:16:10 +0100)
>>>
>>> are available in the Git repository at:
>>>
>>>   git://git.kraxel.org/qemu tags/modules-20200702-pull-request
>>>
>>> for you to fetch changes up to 474a5d66036d18ee5ccaa88364660d05bf32127b:
>>>
>>>   chardev: enable modules, use for braille (2020-07-01 21:08:11 +0200)
>>>
>>> ----------------------------------------------------------------
>>> qom: add support for qom objects in modules.
>>> build some devices (qxl, virtio-gpu, ccid, usb-redir) as modules.
>>> build braille chardev as module.
>>>
>>> note: qemu doesn't rebuild objects on cflags changes (specifically
>>>       -fPIC being added when code is switched from builtin to module).
>>>       Workaround for resulting build errors: "make clean", rebuild.
>>>
>>> ----------------------------------------------------------------
>>>
>>> Gerd Hoffmann (10):
>>>   module: qom module support
>>>   object: qom module support
>>>   qdev: device module support
>>>   build: fix device module builds
>>>   ccid: build smartcard as module
>>>   usb: build usb-redir as module
>>>   vga: build qxl as module
>>>   vga: build virtio-gpu only once
>>>   vga: build virtio-gpu as module
>>>   chardev: enable modules, use for braille
>>
>> No code review at all? :-(
> 
> Well, there have been 5 revisions on the list, partly due to bugs being
> fixed, partly with changes as response to review comments.  So it got
> some review (not much though) even though the v5 series (posted on June
> 22th, so there was more than a week time) didn't got any acks so far.
> 
>> In particular the "build: fix device module
>> builds" commit (as you note in your commit message) does not look at
>> all right.
> 
> I think this stop-gap will do fine as long as we don't have any
> target-specific modules.

Yeah, it's hackish but target-specific modules would be a huge
complication so I don't think we'd be having them anytime soon.  With
Meson removing the unnest-vars logic, the hack would also go away on its
own.  So I guess it's okay.

Paolo