| Message ID | 20200930164949.1425294-1-philmd@redhat.com |
|---|---|
| Headers | show |
| Series | user-mode: Prune build dependencies (part 3) | expand |
On Wed, Sep 30, 2020 at 06:49:38PM +0200, Philippe Mathieu-Daudé wrote: > This is the third part of a series reducing user-mode > dependencies. By stripping out unused code, the build > and testing time is reduced (as is space used by objects). I'm queueing patches 2-9 on machine-next. Thanks! Markus, Eric: I can merge the QAPI patches (1, 11) if I get an Acked-by. I'll send separate comments on patch 10. > > Part 3: > - Extract code not related to user-mode from hw/core/qdev-properties.c > - Reduce user-mode QAPI generated files > > Since v2: > - Fixed UuidInfo placed in incorrect json > - Rebased on Meson > - Include X86CPUFeatureWord unmerged from part 2 > > Since v1: > - Addressed Richard and Paolo review comments > > Patches missing review: QAPI ones :) > - #1 'qapi: Restrict query-uuid command to block code' > - #11 'qapi: Restrict code generated for user-mode' > > Green CI: https://gitlab.com/philmd/qemu/-/pipelines/196505787 > > v2: https://www.mail-archive.com/qemu-devel@nongnu.org/msg688879.html > v1: https://www.mail-archive.com/qemu-devel@nongnu.org/msg688486.html > > Philippe Mathieu-Daudé (11): > qapi: Restrict query-uuid command to block code > hw/core/qdev-properties: Use qemu_strtol() in set_mac() handler > hw/core/qdev-properties: Use qemu_strtoul() in set_pci_host_devaddr() > hw/core/qdev-properties: Fix code style > hw/core/qdev-properties: Export enum-related functions > hw/core/qdev-properties: Export qdev_prop_enum > hw/core/qdev-properties: Export some integer-related functions > hw/core/qdev-properties: Extract system-mode specific properties > hw/core: Add qdev stub for user-mode > target/i386: Restrict X86CPUFeatureWord to X86 targets > qapi: Restrict code generated for user-mode > > qapi/block.json | 30 ++ > qapi/machine-target.json | 45 ++ > qapi/machine.json | 72 --- > hw/core/qdev-prop-internal.h | 30 ++ > include/hw/qdev-properties.h | 1 + > block/iscsi.c | 2 +- > hw/core/qdev-properties-system.c | 687 ++++++++++++++++++++++++++++- > hw/core/qdev-properties.c | 735 ++----------------------------- > stubs/qdev-system.c | 24 + > stubs/uuid.c | 2 +- > target/i386/cpu.c | 2 +- > target/i386/feature-stub.c | 23 + > qapi/meson.build | 51 ++- > stubs/meson.build | 5 +- > target/i386/meson.build | 1 + > 15 files changed, 915 insertions(+), 795 deletions(-) > create mode 100644 hw/core/qdev-prop-internal.h > create mode 100644 stubs/qdev-system.c > create mode 100644 target/i386/feature-stub.c > > -- > 2.26.2 >
On 30/09/20 19:15, Eduardo Habkost wrote: > On Wed, Sep 30, 2020 at 06:49:38PM +0200, Philippe Mathieu-Daudé wrote: >> This is the third part of a series reducing user-mode >> dependencies. By stripping out unused code, the build >> and testing time is reduced (as is space used by objects). > I'm queueing patches 2-9 on machine-next. Thanks! > > Markus, Eric: I can merge the QAPI patches (1, 11) if I get an > Acked-by. > > I'll send separate comments on patch 10. > 1-8 is fine, but I think 9-11 is too much complication (especially not really future-proof) for the benefit. Paolo
On Wed, Sep 30, 2020 at 07:24:24PM +0200, Paolo Bonzini wrote: > On 30/09/20 19:15, Eduardo Habkost wrote: > > On Wed, Sep 30, 2020 at 06:49:38PM +0200, Philippe Mathieu-Daudé wrote: > >> This is the third part of a series reducing user-mode > >> dependencies. By stripping out unused code, the build > >> and testing time is reduced (as is space used by objects). > > I'm queueing patches 2-9 on machine-next. Thanks! > > > > Markus, Eric: I can merge the QAPI patches (1, 11) if I get an > > Acked-by. > > > > I'll send separate comments on patch 10. > > > > 1-8 is fine, but I think 9-11 is too much complication (especially not > really future-proof) for the benefit. I'll dequeue patch 9 while this is discussed.
Paolo Bonzini <pbonzini@redhat.com> writes: > On 30/09/20 19:15, Eduardo Habkost wrote: >> On Wed, Sep 30, 2020 at 06:49:38PM +0200, Philippe Mathieu-Daudé wrote: >>> This is the third part of a series reducing user-mode >>> dependencies. By stripping out unused code, the build >>> and testing time is reduced (as is space used by objects). >> I'm queueing patches 2-9 on machine-next. Thanks! >> >> Markus, Eric: I can merge the QAPI patches (1, 11) if I get an >> Acked-by. >> >> I'll send separate comments on patch 10. >> > > 1-8 is fine, but I think 9-11 is too much complication (especially not > really future-proof) for the benefit. Isn't qdev considered an internal API for our object and device lifetime handling (which should be shared) versus QAPI which only exists for system emulation and tool integration? That is of course assuming libvirt is never going to want to know about linux-user emulation? > > Paolo
Il mer 30 set 2020, 20:57 Alex Bennée <alex.bennee@linaro.org> ha scritto: > > 1-8 is fine, but I think 9-11 is too much complication (especially not > > really future-proof) for the benefit. > > Isn't qdev considered an internal API for our object and device lifetime > handling (which should be shared) versus QAPI which only exists for > system emulation and tool integration? > qdev is nothing more than a bunch of QOM classes, and QAPI is an integral part of QOM (though properties, which are used when setting up CPUs in user more emulation) Therefore, even though most of the QAPI schema is specific to system emulation and tools, a small part is used by common code. Paolo >
On 9/30/20 7:27 PM, Eduardo Habkost wrote: > On Wed, Sep 30, 2020 at 07:24:24PM +0200, Paolo Bonzini wrote: >> On 30/09/20 19:15, Eduardo Habkost wrote: >>> On Wed, Sep 30, 2020 at 06:49:38PM +0200, Philippe Mathieu-Daudé wrote: >>>> This is the third part of a series reducing user-mode >>>> dependencies. By stripping out unused code, the build >>>> and testing time is reduced (as is space used by objects). >>> I'm queueing patches 2-9 on machine-next. Thanks! >>> >>> Markus, Eric: I can merge the QAPI patches (1, 11) if I get an >>> Acked-by. >>> >>> I'll send separate comments on patch 10. >>> >> >> 1-8 is fine, but I think 9-11 is too much complication (especially not >> really future-proof) for the benefit. > > I'll dequeue patch 9 while this is discussed. Please also dequeue 1 :( Markus hasn't sent negative comments on 2-8 so these should be OK.