From: Eduardo Habkost <ehabkost@redhat.com> To: Paolo Bonzini <pbonzini@redhat.com> Cc: qemu-devel@nongnu.org, Thomas Huth <thuth@redhat.com>, Peter Maydell <peter.maydell@linaro.org>, Markus Armbruster <armbru@redhat.com>, Like Xu <like.xu@linux.intel.com> Subject: Re: [Qemu-devel] [PATCH 3/4] qdev: Don't compile hotplug code in user-mode emulation Date: Fri, 26 Apr 2019 08:21:35 -0300 [thread overview] Message-ID: <20190426112135.GA30873@habkost.net> (raw) In-Reply-To: <bbdf7fb5-8f68-582b-2c57-5cf0a522237d@redhat.com> On Fri, Apr 26, 2019 at 10:27:58AM +0200, Paolo Bonzini wrote: > On 25/04/19 22:00, Eduardo Habkost wrote: > > diff --git a/hw/core/qdev-hotplug-stubs.c b/hw/core/qdev-hotplug-stubs.c > > new file mode 100644 > > index 0000000000..c710f23388 > > --- /dev/null > > +++ b/hw/core/qdev-hotplug-stubs.c > > @@ -0,0 +1,44 @@ > > +/* > > + * qdev hotplug handler stubs (for user-mode emulation and unit tests) > > Can you explain the issue with unit tests in the commit message? I don't think there are issues with unit tests. I just thought it was pointless to link qdev-hotplug.o into unit tests binaries if no hotplug handler object is created by them. What do you think? Should I keep qdev-hotplug.o and hotplug.o in the unit tests binaries? > > > + * Copyright (c) 2019 Red Hat Inc > > + * > > + * Authors: > > + * Eduardo Habkost <ehabkost@redhat.com> > > + * > > + * This library is free software; you can redistribute it and/or > > + * modify it under the terms of the GNU Lesser General Public > > + * License as published by the Free Software Foundation; either > > + * version 2 of the License, or (at your option) any later version. > > + * > > + * This library is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > > + * Lesser General Public License for more details. > > + * > > + * You should have received a copy of the GNU Lesser General Public > > + * License along with this library; if not, see <http://www.gnu.org/licenses/>. > > + */ > > + > > +#include "qemu/osdep.h" > > +#include "hw/qdev-core.h" > > +#include "hw/hotplug.h" > > + > > +HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev) > > +{ > > + return NULL; > > +} > > + > > +void hotplug_handler_pre_plug(HotplugHandler *plug_handler, > > + DeviceState *plugged_dev, > > + Error **errp) > > +{ > > + assert(plug_handler == NULL); > > +} > > + > > +void hotplug_handler_plug(HotplugHandler *plug_handler, > > + DeviceState *plugged_dev, > > + Error **errp) > > +{ > > + assert(plug_handler == NULL); > > +} > > Would it work if you instead make these functions (and the others in > hw/core/hotplug.c) inlines in include/hw/hotplug.h? > > Then all that remains is qdev_get_hotplug_handler. I think that would work. I'll do that in v2, thanks! -- Eduardo
WARNING: multiple messages have this Message-ID (diff)
From: Eduardo Habkost <ehabkost@redhat.com> To: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org>, Thomas Huth <thuth@redhat.com>, qemu-devel@nongnu.org, Like Xu <like.xu@linux.intel.com>, Markus Armbruster <armbru@redhat.com> Subject: Re: [Qemu-devel] [PATCH 3/4] qdev: Don't compile hotplug code in user-mode emulation Date: Fri, 26 Apr 2019 08:21:35 -0300 [thread overview] Message-ID: <20190426112135.GA30873@habkost.net> (raw) Message-ID: <20190426112135.LokyD8U6WGZ7QpJfLxS-Ysdpq8-kA-YnOoCLvG-7wHk@z> (raw) In-Reply-To: <bbdf7fb5-8f68-582b-2c57-5cf0a522237d@redhat.com> On Fri, Apr 26, 2019 at 10:27:58AM +0200, Paolo Bonzini wrote: > On 25/04/19 22:00, Eduardo Habkost wrote: > > diff --git a/hw/core/qdev-hotplug-stubs.c b/hw/core/qdev-hotplug-stubs.c > > new file mode 100644 > > index 0000000000..c710f23388 > > --- /dev/null > > +++ b/hw/core/qdev-hotplug-stubs.c > > @@ -0,0 +1,44 @@ > > +/* > > + * qdev hotplug handler stubs (for user-mode emulation and unit tests) > > Can you explain the issue with unit tests in the commit message? I don't think there are issues with unit tests. I just thought it was pointless to link qdev-hotplug.o into unit tests binaries if no hotplug handler object is created by them. What do you think? Should I keep qdev-hotplug.o and hotplug.o in the unit tests binaries? > > > + * Copyright (c) 2019 Red Hat Inc > > + * > > + * Authors: > > + * Eduardo Habkost <ehabkost@redhat.com> > > + * > > + * This library is free software; you can redistribute it and/or > > + * modify it under the terms of the GNU Lesser General Public > > + * License as published by the Free Software Foundation; either > > + * version 2 of the License, or (at your option) any later version. > > + * > > + * This library is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > > + * Lesser General Public License for more details. > > + * > > + * You should have received a copy of the GNU Lesser General Public > > + * License along with this library; if not, see <http://www.gnu.org/licenses/>. > > + */ > > + > > +#include "qemu/osdep.h" > > +#include "hw/qdev-core.h" > > +#include "hw/hotplug.h" > > + > > +HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev) > > +{ > > + return NULL; > > +} > > + > > +void hotplug_handler_pre_plug(HotplugHandler *plug_handler, > > + DeviceState *plugged_dev, > > + Error **errp) > > +{ > > + assert(plug_handler == NULL); > > +} > > + > > +void hotplug_handler_plug(HotplugHandler *plug_handler, > > + DeviceState *plugged_dev, > > + Error **errp) > > +{ > > + assert(plug_handler == NULL); > > +} > > Would it work if you instead make these functions (and the others in > hw/core/hotplug.c) inlines in include/hw/hotplug.h? > > Then all that remains is qdev_get_hotplug_handler. I think that would work. I'll do that in v2, thanks! -- Eduardo
next prev parent reply other threads:[~2019-04-26 11:21 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-25 20:00 [Qemu-devel] [PATCH 0/4] Remove some qdev_get_machine() calls from CONFIG_USER_ONLY Eduardo Habkost 2019-04-25 20:00 ` Eduardo Habkost 2019-04-25 20:00 ` [Qemu-devel] [PATCH 1/4] machine: Move gpio code to hw/core/gpio.c Eduardo Habkost 2019-04-25 20:00 ` Eduardo Habkost 2021-11-01 16:24 ` Philippe Mathieu-Daudé 2019-04-25 20:00 ` [Qemu-devel] [PATCH 2/4] move qdev hotplug code to qdev-hotplug.c Eduardo Habkost 2019-04-25 20:00 ` Eduardo Habkost 2019-04-25 20:00 ` [Qemu-devel] [PATCH 3/4] qdev: Don't compile hotplug code in user-mode emulation Eduardo Habkost 2019-04-25 20:00 ` Eduardo Habkost 2019-04-26 8:27 ` Paolo Bonzini 2019-04-26 8:27 ` Paolo Bonzini 2019-04-26 11:21 ` Eduardo Habkost [this message] 2019-04-26 11:21 ` Eduardo Habkost 2019-04-25 20:00 ` [Qemu-devel] [PATCH 4/4] qdev-hotplug: Don't check type of qdev_get_machine() Eduardo Habkost 2019-04-25 20:00 ` Eduardo Habkost 2021-11-01 18:03 ` Philippe Mathieu-Daudé 2019-04-25 20:09 ` [Qemu-devel] [PATCH 0/4] Remove some qdev_get_machine() calls from CONFIG_USER_ONLY no-reply 2019-04-25 20:09 ` no-reply 2019-04-26 8:55 ` Like Xu 2019-04-26 8:55 ` Like Xu 2019-05-02 20:24 ` Eduardo Habkost 2019-05-02 20:24 ` Eduardo Habkost 2019-05-06 14:34 ` Markus Armbruster 2021-11-01 18:27 ` Philippe Mathieu-Daudé
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190426112135.GA30873@habkost.net \ --to=ehabkost@redhat.com \ --cc=armbru@redhat.com \ --cc=like.xu@linux.intel.com \ --cc=pbonzini@redhat.com \ --cc=peter.maydell@linaro.org \ --cc=qemu-devel@nongnu.org \ --cc=thuth@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).