docs/devel/qom.rst | 91 ++-- hw/core/qdev-prop-internal.h | 30 ++ include/exec/memory.h | 6 +- include/hw/qdev-properties.h | 1 + include/qom/object.h | 38 +- hw/core/cpu.c | 1 + hw/core/numa.c | 8 +- hw/core/qdev-properties-system.c | 687 ++++++++++++++++++++++++++++- hw/core/qdev-properties.c | 735 ++----------------------------- qom/object.c | 3 +- scripts/kernel-doc | 16 +- 11 files changed, 831 insertions(+), 785 deletions(-) create mode 100644 hw/core/qdev-prop-internal.h
The following changes since commit 36d9c2883e55c863b622b99f0ebb5143f0001401: readthedocs: build with Python 3.6 (2020-10-05 16:30:45 +0100) are available in the Git repository at: git://github.com/ehabkost/qemu.git tags/machine-next-pull-request for you to fetch changes up to fec5c4b6d3b7f3ffcfcbe1714e0405df6de2a222: kernel-doc: Remove $decl_type='type name' hack (2020-10-05 12:48:11 -0400) ---------------------------------------------------------------- machine + QOM queue, 2020-10-05 * QOM documentation fixes and cleanups (Eduardo Habkost) * user-mode: Prune build dependencies (Philippe Mathieu-Daudé) * qom: Improve error message (Philippe Mathieu-Daudé) * numa: hmat: require parent cache description before the next level one (Igor Mammedov) ---------------------------------------------------------------- Eduardo Habkost (11): qom: Fix DECLARE_*CHECKER documentation docs/devel/qom: Fix indentation of bulleted list docs/devel/qom: Fix indentation of code blocks docs/devel/qom: Use *emphasis* for emphasis docs/devel/qom: Remove usage of <code> docs/devel/qom: Avoid long lines kernel-doc: Handle function typedefs that return pointers kernel-doc: Handle function typedefs without asterisks qom: Explicitly tag doc comments for typedefs and structs memory: Explicitly tag doc comments for structs kernel-doc: Remove $decl_type='type name' hack Igor Mammedov (1): numa: hmat: require parent cache description before the next level one Philippe Mathieu-Daudé (9): 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/cpu: Add missing 'exec/cpu-common.h' include qom: Improve error message displayed with missing object properties docs/devel/qom.rst | 91 ++-- hw/core/qdev-prop-internal.h | 30 ++ include/exec/memory.h | 6 +- include/hw/qdev-properties.h | 1 + include/qom/object.h | 38 +- hw/core/cpu.c | 1 + hw/core/numa.c | 8 +- hw/core/qdev-properties-system.c | 687 ++++++++++++++++++++++++++++- hw/core/qdev-properties.c | 735 ++----------------------------- qom/object.c | 3 +- scripts/kernel-doc | 16 +- 11 files changed, 831 insertions(+), 785 deletions(-) create mode 100644 hw/core/qdev-prop-internal.h -- 2.26.2
On Mon, 5 Oct 2020 at 22:10, Eduardo Habkost <ehabkost@redhat.com> wrote:
>
> The following changes since commit 36d9c2883e55c863b622b99f0ebb5143f0001401:
>
> readthedocs: build with Python 3.6 (2020-10-05 16:30:45 +0100)
>
> are available in the Git repository at:
>
> git://github.com/ehabkost/qemu.git tags/machine-next-pull-request
>
> for you to fetch changes up to fec5c4b6d3b7f3ffcfcbe1714e0405df6de2a222:
>
> kernel-doc: Remove $decl_type='type name' hack (2020-10-05 12:48:11 -0400)
>
> ----------------------------------------------------------------
> machine + QOM queue, 2020-10-05
>
> * QOM documentation fixes and cleanups (Eduardo Habkost)
> * user-mode: Prune build dependencies (Philippe Mathieu-Daudé)
> * qom: Improve error message (Philippe Mathieu-Daudé)
> * numa: hmat: require parent cache description before the next
> level one (Igor Mammedov)
>
> ----------------------------------------------------------------
Compile failure on OSX:
../../hw/core/numa.c:429:20: error: format specifies type 'unsigned
char' but the argument has type 'int' [-Werror,-Wformat]
node->level - 1);
^~~~~~~~~~~~~~~~
/Users/pm215/src/qemu-for-merges/include/qapi/error.h:319:35: note:
expanded from macro 'error_setg'
(fmt), ## __VA_ARGS__)
~~~ ^~~~~~~~~~~
1 error generated.
thanks
-- PMM
On Tue, Oct 06, 2020 at 03:03:57PM +0100, Peter Maydell wrote: > On Mon, 5 Oct 2020 at 22:10, Eduardo Habkost <ehabkost@redhat.com> wrote: > > > > The following changes since commit 36d9c2883e55c863b622b99f0ebb5143f0001401: > > > > readthedocs: build with Python 3.6 (2020-10-05 16:30:45 +0100) > > > > are available in the Git repository at: > > > > git://github.com/ehabkost/qemu.git tags/machine-next-pull-request > > > > for you to fetch changes up to fec5c4b6d3b7f3ffcfcbe1714e0405df6de2a222: > > > > kernel-doc: Remove $decl_type='type name' hack (2020-10-05 12:48:11 -0400) > > > > ---------------------------------------------------------------- > > machine + QOM queue, 2020-10-05 > > > > * QOM documentation fixes and cleanups (Eduardo Habkost) > > * user-mode: Prune build dependencies (Philippe Mathieu-Daudé) > > * qom: Improve error message (Philippe Mathieu-Daudé) > > * numa: hmat: require parent cache description before the next > > level one (Igor Mammedov) > > > > ---------------------------------------------------------------- > > Compile failure on OSX: > > ../../hw/core/numa.c:429:20: error: format specifies type 'unsigned > char' but the argument has type 'int' [-Werror,-Wformat] > node->level - 1); > ^~~~~~~~~~~~~~~~ > /Users/pm215/src/qemu-for-merges/include/qapi/error.h:319:35: note: > expanded from macro 'error_setg' > (fmt), ## __VA_ARGS__) > ~~~ ^~~~~~~~~~~ > 1 error generated. Is there a CI system where this is tested? I'd like to be able to detect this kind of failure before sending pull requests. -- Eduardo
On Tue, 6 Oct 2020 at 15:36, Eduardo Habkost <ehabkost@redhat.com> wrote: > > On Tue, Oct 06, 2020 at 03:03:57PM +0100, Peter Maydell wrote: > > Compile failure on OSX: > > > > ../../hw/core/numa.c:429:20: error: format specifies type 'unsigned > > char' but the argument has type 'int' [-Werror,-Wformat] > > node->level - 1); > > ^~~~~~~~~~~~~~~~ > > /Users/pm215/src/qemu-for-merges/include/qapi/error.h:319:35: note: > > expanded from macro 'error_setg' > > (fmt), ## __VA_ARGS__) > > ~~~ ^~~~~~~~~~~ > > 1 error generated. > > Is there a CI system where this is tested? I'd like to be able > to detect this kind of failure before sending pull requests. Currently this is still my ad-hoc setup. I think there is some CI that tests OSX compiles, though I have no idea how individual maintainers set up to use it. thanks -- PMM
On Tue, Oct 06, 2020 at 03:38:56PM +0100, Peter Maydell wrote: > On Tue, 6 Oct 2020 at 15:36, Eduardo Habkost <ehabkost@redhat.com> wrote: > > > > On Tue, Oct 06, 2020 at 03:03:57PM +0100, Peter Maydell wrote: > > > Compile failure on OSX: > > > > > > ../../hw/core/numa.c:429:20: error: format specifies type 'unsigned > > > char' but the argument has type 'int' [-Werror,-Wformat] > > > node->level - 1); > > > ^~~~~~~~~~~~~~~~ > > > /Users/pm215/src/qemu-for-merges/include/qapi/error.h:319:35: note: > > > expanded from macro 'error_setg' > > > (fmt), ## __VA_ARGS__) > > > ~~~ ^~~~~~~~~~~ > > > 1 error generated. > > > > Is there a CI system where this is tested? I'd like to be able > > to detect this kind of failure before sending pull requests. > > Currently this is still my ad-hoc setup. I think there is > some CI that tests OSX compiles, though I have no idea how > individual maintainers set up to use it. Cirrus CI will cover macOS builds. You just need to register with Cirrus CI via your GitLab login, then pushing a branch to gitlab should trigger both GitLab CI and Cirrus CI, which covers a vast majority of combinations. If you register with Travis and push to GitHub too, you'll get some non-x86 coverage too. Alternatively setup mirroring from GitLab to GitHub, so you don't have to separately push to GitHub, just use GitLab to trigger all three CI systems. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 06/10/2020 16.42, Daniel P. Berrangé wrote: > On Tue, Oct 06, 2020 at 03:38:56PM +0100, Peter Maydell wrote: >> On Tue, 6 Oct 2020 at 15:36, Eduardo Habkost <ehabkost@redhat.com> wrote: >>> >>> On Tue, Oct 06, 2020 at 03:03:57PM +0100, Peter Maydell wrote: >>>> Compile failure on OSX: >>>> >>>> ../../hw/core/numa.c:429:20: error: format specifies type 'unsigned >>>> char' but the argument has type 'int' [-Werror,-Wformat] >>>> node->level - 1); >>>> ^~~~~~~~~~~~~~~~ >>>> /Users/pm215/src/qemu-for-merges/include/qapi/error.h:319:35: note: >>>> expanded from macro 'error_setg' >>>> (fmt), ## __VA_ARGS__) >>>> ~~~ ^~~~~~~~~~~ >>>> 1 error generated. >>> >>> Is there a CI system where this is tested? I'd like to be able >>> to detect this kind of failure before sending pull requests. >> >> Currently this is still my ad-hoc setup. I think there is >> some CI that tests OSX compiles, though I have no idea how >> individual maintainers set up to use it. > > Cirrus CI will cover macOS builds. You just need to register with > Cirrus CI via your GitLab login, then pushing a branch to gitlab > should trigger both GitLab CI and Cirrus CI, which covers a vast > majority of combinations. I think Cirrus-CI needs a github account? Is there a way to use Gitlab now instead? (just like Travis recently added Gitlab support?) We should eventually set up the cirrus-run tool, so we can use gitlab, too, but I think you then still need at least a dummy github account to be able to use it, don't you? Thomas
Il mar 6 ott 2020, 20:47 Thomas Huth <thuth@redhat.com> ha scritto: > I think Cirrus-CI needs a github account? Is there a way to use Gitlab now > instead? (just like Travis recently added Gitlab support?) > It does only support GitHub. In theory you can set up an automatic push from Gitlab to GitHub but it doesn't work well if you force push to the Gitlab repository. We should eventually set up the cirrus-run tool, so we can use gitlab, too, > but I think you then still need at least a dummy github account to be able > to use it, don't you? > Yes, that's correct. Paolo > Thomas > >
On Tue, Oct 06, 2020 at 09:10:59PM +0200, Paolo Bonzini wrote: > Il mar 6 ott 2020, 20:47 Thomas Huth <thuth@redhat.com> ha scritto: > > > I think Cirrus-CI needs a github account? Is there a way to use Gitlab now > > instead? (just like Travis recently added Gitlab support?) > > > > It does only support GitHub. In theory you can set up an automatic push > from Gitlab to GitHub but it doesn't work well if you force push to the > Gitlab repository. I've configured my GitLab qemu repo to run a "Push" mirror to GitHub and it propagates force pushes for branches too. There is some rate limiting though. It won't mirror more frequently than every 5 minutes, and so in worst case you could be waiting upto just under 10 minutes for it to sync. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Oct 06, 2020 at 08:47:29PM +0200, Thomas Huth wrote: > On 06/10/2020 16.42, Daniel P. Berrangé wrote: > > On Tue, Oct 06, 2020 at 03:38:56PM +0100, Peter Maydell wrote: > > > On Tue, 6 Oct 2020 at 15:36, Eduardo Habkost <ehabkost@redhat.com> wrote: > > > > > > > > On Tue, Oct 06, 2020 at 03:03:57PM +0100, Peter Maydell wrote: > > > > > Compile failure on OSX: > > > > > > > > > > ../../hw/core/numa.c:429:20: error: format specifies type 'unsigned > > > > > char' but the argument has type 'int' [-Werror,-Wformat] > > > > > node->level - 1); > > > > > ^~~~~~~~~~~~~~~~ > > > > > /Users/pm215/src/qemu-for-merges/include/qapi/error.h:319:35: note: > > > > > expanded from macro 'error_setg' > > > > > (fmt), ## __VA_ARGS__) > > > > > ~~~ ^~~~~~~~~~~ > > > > > 1 error generated. > > > > > > > > Is there a CI system where this is tested? I'd like to be able > > > > to detect this kind of failure before sending pull requests. > > > > > > Currently this is still my ad-hoc setup. I think there is > > > some CI that tests OSX compiles, though I have no idea how > > > individual maintainers set up to use it. > > > > Cirrus CI will cover macOS builds. You just need to register with > > Cirrus CI via your GitLab login, then pushing a branch to gitlab > > should trigger both GitLab CI and Cirrus CI, which covers a vast > > majority of combinations. > > I think Cirrus-CI needs a github account? Is there a way to use Gitlab now > instead? (just like Travis recently added Gitlab support?) Sorry, I was mixing up Travis and Cirrus. > We should eventually set up the cirrus-run tool, so we can use gitlab, too, > but I think you then still need at least a dummy github account to be able > to use it, don't you? Yes, you still need a github account. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 06/10/20 16:36, Eduardo Habkost wrote: > On Tue, Oct 06, 2020 at 03:03:57PM +0100, Peter Maydell wrote: >> On Mon, 5 Oct 2020 at 22:10, Eduardo Habkost <ehabkost@redhat.com> wrote: >>> >>> The following changes since commit 36d9c2883e55c863b622b99f0ebb5143f0001401: >>> >>> readthedocs: build with Python 3.6 (2020-10-05 16:30:45 +0100) >>> >>> are available in the Git repository at: >>> >>> git://github.com/ehabkost/qemu.git tags/machine-next-pull-request >>> >>> for you to fetch changes up to fec5c4b6d3b7f3ffcfcbe1714e0405df6de2a222: >>> >>> kernel-doc: Remove $decl_type='type name' hack (2020-10-05 12:48:11 -0400) >>> >>> ---------------------------------------------------------------- >>> machine + QOM queue, 2020-10-05 >>> >>> * QOM documentation fixes and cleanups (Eduardo Habkost) >>> * user-mode: Prune build dependencies (Philippe Mathieu-Daudé) >>> * qom: Improve error message (Philippe Mathieu-Daudé) >>> * numa: hmat: require parent cache description before the next >>> level one (Igor Mammedov) >>> >>> ---------------------------------------------------------------- >> >> Compile failure on OSX: >> >> ../../hw/core/numa.c:429:20: error: format specifies type 'unsigned >> char' but the argument has type 'int' [-Werror,-Wformat] >> node->level - 1); >> ^~~~~~~~~~~~~~~~ >> /Users/pm215/src/qemu-for-merges/include/qapi/error.h:319:35: note: >> expanded from macro 'error_setg' >> (fmt), ## __VA_ARGS__) >> ~~~ ^~~~~~~~~~~ >> 1 error generated. > > Is there a CI system where this is tested? I'd like to be able > to detect this kind of failure before sending pull requests. Possibly Cirrus CI? You have to add it to your account (https://cirrus-ci.org/guide/quick-start/) and then it triggers on any push to GitHub; there's nothing else you have to do. Paolo
On Tue, 6 Oct 2020 10:36:37 -0400 Eduardo Habkost <ehabkost@redhat.com> wrote: > On Tue, Oct 06, 2020 at 03:03:57PM +0100, Peter Maydell wrote: > > On Mon, 5 Oct 2020 at 22:10, Eduardo Habkost <ehabkost@redhat.com> wrote: > > > > > > The following changes since commit 36d9c2883e55c863b622b99f0ebb5143f0001401: > > > > > > readthedocs: build with Python 3.6 (2020-10-05 16:30:45 +0100) > > > > > > are available in the Git repository at: > > > > > > git://github.com/ehabkost/qemu.git tags/machine-next-pull-request > > > > > > for you to fetch changes up to fec5c4b6d3b7f3ffcfcbe1714e0405df6de2a222: > > > > > > kernel-doc: Remove $decl_type='type name' hack (2020-10-05 12:48:11 -0400) > > > > > > ---------------------------------------------------------------- > > > machine + QOM queue, 2020-10-05 > > > > > > * QOM documentation fixes and cleanups (Eduardo Habkost) > > > * user-mode: Prune build dependencies (Philippe Mathieu-Daudé) > > > * qom: Improve error message (Philippe Mathieu-Daudé) > > > * numa: hmat: require parent cache description before the next > > > level one (Igor Mammedov) > > > > > > ---------------------------------------------------------------- > > > > Compile failure on OSX: > > > > ../../hw/core/numa.c:429:20: error: format specifies type 'unsigned > > char' but the argument has type 'int' [-Werror,-Wformat] > > node->level - 1); > > ^~~~~~~~~~~~~~~~ > > /Users/pm215/src/qemu-for-merges/include/qapi/error.h:319:35: note: > > expanded from macro 'error_setg' > > (fmt), ## __VA_ARGS__) > > ~~~ ^~~~~~~~~~~ > > 1 error generated. > > Is there a CI system where this is tested? I'd like to be able > to detect this kind of failure before sending pull requests. I usually use travis-ci, but for this patch I didn't run it via CI for some reason. Just posted fixed v2. (it looks like pushing to github doesn't trigger travis build anymore)
On Tue, 6 Oct 2020 17:04:18 +0200 Igor Mammedov <imammedo@redhat.com> wrote: > On Tue, 6 Oct 2020 10:36:37 -0400 > Eduardo Habkost <ehabkost@redhat.com> wrote: > > > On Tue, Oct 06, 2020 at 03:03:57PM +0100, Peter Maydell wrote: > > > On Mon, 5 Oct 2020 at 22:10, Eduardo Habkost <ehabkost@redhat.com> wrote: > > > > > > > > The following changes since commit 36d9c2883e55c863b622b99f0ebb5143f0001401: > > > > > > > > readthedocs: build with Python 3.6 (2020-10-05 16:30:45 +0100) > > > > > > > > are available in the Git repository at: > > > > > > > > git://github.com/ehabkost/qemu.git tags/machine-next-pull-request > > > > > > > > for you to fetch changes up to fec5c4b6d3b7f3ffcfcbe1714e0405df6de2a222: > > > > > > > > kernel-doc: Remove $decl_type='type name' hack (2020-10-05 12:48:11 -0400) > > > > > > > > ---------------------------------------------------------------- > > > > machine + QOM queue, 2020-10-05 > > > > > > > > * QOM documentation fixes and cleanups (Eduardo Habkost) > > > > * user-mode: Prune build dependencies (Philippe Mathieu-Daudé) > > > > * qom: Improve error message (Philippe Mathieu-Daudé) > > > > * numa: hmat: require parent cache description before the next > > > > level one (Igor Mammedov) > > > > > > > > ---------------------------------------------------------------- > > > > > > Compile failure on OSX: > > > > > > ../../hw/core/numa.c:429:20: error: format specifies type 'unsigned > > > char' but the argument has type 'int' [-Werror,-Wformat] > > > node->level - 1); > > > ^~~~~~~~~~~~~~~~ > > > /Users/pm215/src/qemu-for-merges/include/qapi/error.h:319:35: note: > > > expanded from macro 'error_setg' > > > (fmt), ## __VA_ARGS__) > > > ~~~ ^~~~~~~~~~~ > > > 1 error generated. > > > > Is there a CI system where this is tested? I'd like to be able > > to detect this kind of failure before sending pull requests. > I usually use travis-ci, but for this patch I didn't run it via CI for some reason. > Just posted fixed v2. > > (it looks like pushing to github doesn't trigger travis build anymore) Looks like travis-ci lost previous authorizations to my github repo, but giving a new one didn't help. Something wrong with current QEMU master, travis-ci doesn't recognize QEMU repo a valid anymore.
On 06/10/20 17:23, Igor Mammedov wrote: > Looks like travis-ci lost previous authorizations to my github repo, > but giving a new one didn't help. > > Something wrong with current QEMU master, travis-ci doesn't recognize QEMU repo a valid anymore. > Interesting, I use Travis->Gitlab integration and even though builds are still triggered, they don't appear in the Gitlab CI page. So the configuration is okay, but something seems to be wrong on the Travis side. Paolo
On Tue, 6 Oct 2020 17:42:28 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote: > On 06/10/20 17:23, Igor Mammedov wrote: > > Looks like travis-ci lost previous authorizations to my github repo, > > but giving a new one didn't help. > > > > Something wrong with current QEMU master, travis-ci doesn't recognize QEMU repo a valid anymore. > > > > Interesting, I use Travis->Gitlab integration and even though builds are > still triggered, they don't appear in the Gitlab CI page. So the > configuration is okay, but something seems to be wrong on the Travis side. If one enables access to all repositories on account, then even if travis-ci doesn't show QEMU repo as accessible one, it seems that there is a new build in 'received' state, maybe it will start building eventually. > > Paolo >
On 06/10/2020 18.14, Igor Mammedov wrote: > On Tue, 6 Oct 2020 17:42:28 +0200 > Paolo Bonzini <pbonzini@redhat.com> wrote: > >> On 06/10/20 17:23, Igor Mammedov wrote: >>> Looks like travis-ci lost previous authorizations to my github repo, >>> but giving a new one didn't help. >>> >>> Something wrong with current QEMU master, travis-ci doesn't recognize QEMU repo a valid anymore. >>> >> >> Interesting, I use Travis->Gitlab integration and even though builds are >> still triggered, they don't appear in the Gitlab CI page. So the >> configuration is okay, but something seems to be wrong on the Travis side. > > If one enables access to all repositories on account, then even if travis-ci > doesn't show QEMU repo as accessible one, it seems that there is a new build in > 'received' state, maybe it will start building eventually. It works for me (via my github account): https://travis-ci.com/github/huth/qemu/builds/188441775 ... maybe it was just a temporary hickup? Anyway, we do not test macOS on Travis anymore (see commit 22a231950c50d3), so this is likely not helpful for Eduardo's original problem... Cirrus-CI is the way to go if you need macOS test coverage. Thomas
© 2016 - 2025 Red Hat, Inc.