From: Paolo Bonzini <pbonzini@redhat.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>,
qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 07/11] qemu-char: Move incrementing of avail_connections to qdev-properties-system
Date: Tue, 26 Mar 2013 14:50:05 +0100 [thread overview]
Message-ID: <5151A78D.5010708@redhat.com> (raw)
In-Reply-To: <5151A301.30503@redhat.com>
Il 26/03/2013 14:30, Hans de Goede ha scritto:
> Hi,
>
> On 03/26/2013 02:07 PM, Paolo Bonzini wrote:
>> Il 26/03/2013 11:07, Hans de Goede ha scritto:
>>> The decrement of avail_connections is done in qdev-properties-system
>>> move
>>> the increment there too for proper balancing of the calls.
>>>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> ---
>>> hw/qdev-properties-system.c | 6 ++++--
>>> qemu-char.c | 2 --
>>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/hw/qdev-properties-system.c b/hw/qdev-properties-system.c
>>> index 8795144..12a87d5 100644
>>> --- a/hw/qdev-properties-system.c
>>> +++ b/hw/qdev-properties-system.c
>>> @@ -136,9 +136,11 @@ static void release_chr(Object *obj, const char
>>> *name, void *opaque)
>>> DeviceState *dev = DEVICE(obj);
>>> Property *prop = opaque;
>>> CharDriverState **ptr = qdev_get_prop_ptr(dev, prop);
>>> + CharDriverState *chr = *ptr;
>>>
>>> - if (*ptr) {
>>> - qemu_chr_add_handlers(*ptr, NULL, NULL, NULL, NULL);
>>> + if (chr) {
>>> + qemu_chr_add_handlers(chr, NULL, NULL, NULL, NULL);
>>> + ++chr->avail_connections;
>>> }
>>> }
>>>
>>> diff --git a/qemu-char.c b/qemu-char.c
>>> index 8a66627..368e7f5 100644
>>> --- a/qemu-char.c
>>> +++ b/qemu-char.c
>>> @@ -197,8 +197,6 @@ void qemu_chr_add_handlers(CharDriverState *s,
>>> int fe_open;
>>>
>>> if (!opaque && !fd_can_read && !fd_read && !fd_event) {
>>> - /* chr driver being released. */
>>> - ++s->avail_connections;
>>> fe_open = 0;
>>> } else {
>>> fe_open = 1;
>>>
>>
>> I think this is still wrong (though better than before this patch).
>> This is still not giving an error:
>>
>> qemu-kvm \
>> -chardev stdio,id=foo -device isa-serial,chardev=foo \
>> -mon chardev=foo
>>
>> because other users of -chardev (monitor and rng-egd), are not
>> decrementing avail_connections. Can you look at it in a follow-up?
>
> I know, I ended up writing this patch mostly as a side-effect.
>
> I can put further fixing this on my TODO list but first I've some
> questions about this which need answering:
>
> 1) For most problematic devices, the proper fix would be to make them
> use a chardev qdev property for there chardev usage, and then this
> would be automatically fixed, agreed?
At least on x86, all devices already use a chardev qdev property.
> 2) For some this may not fly and a manual inc / dec of avail_connections
> is necessary, ie the monitor, agreed?
>
> 3) One weird case which I encountered when working on this I noticed
> that backends/rng-egd.c has its chardev as a string qdev-property, rather
> then as a chardev qdev-property and then it does a qemu_chr_find itself,
> is this intentional, iow is there some reason having it as a
> chardev qdev-property does not work ?
The infrastructure for chardev qdev properties right now is only used
within devices. The right thing to do would be to make chardevs QOM
objects. Then you do not need any special code, just make chardevs QOM
links.
Paolo
next prev parent reply other threads:[~2013-03-26 13:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 10:07 [Qemu-devel] [PATCH 0/11] chardev frontend open handling cleanup v2 Hans de Goede
2013-03-26 10:07 ` [Qemu-devel] [PATCH 01/11] qemu-char: Rename opened to be_open Hans de Goede
2013-03-26 10:07 ` [Qemu-devel] [PATCH 02/11] qemu-char: Rename qemu_chr_generic_open to qemu_chr_be_generic_open Hans de Goede
2013-03-26 10:07 ` [Qemu-devel] [PATCH 03/11] qemu-char: Add fe_open tracking Hans de Goede
2013-03-26 10:07 ` [Qemu-devel] [PATCH 04/11] qemu-char: Automatically do fe_open / fe_close on qemu_chr_add_handlers Hans de Goede
2013-03-26 10:07 ` [Qemu-devel] [PATCH 05/11] qemu-char: Cleanup: consolidate fe_open/fe_close into fe_set_open Hans de Goede
2013-03-26 10:07 ` [Qemu-devel] [PATCH 06/11] qemu-char: Consolidate guest_close/guest_open into a set_fe_open callback Hans de Goede
2013-03-26 10:07 ` [Qemu-devel] [PATCH 07/11] qemu-char: Move incrementing of avail_connections to qdev-properties-system Hans de Goede
2013-03-26 13:07 ` Paolo Bonzini
2013-03-26 13:30 ` Hans de Goede
2013-03-26 13:50 ` Paolo Bonzini [this message]
2013-03-27 14:09 ` Hans de Goede
2013-03-27 14:58 ` Paolo Bonzini
2013-03-27 15:16 ` Hans de Goede
2013-03-26 10:08 ` [Qemu-devel] [PATCH 08/11] qemu-char: add_handlers: Don't re-send the be_open event on unregister Hans de Goede
2013-03-26 10:08 ` [Qemu-devel] [PATCH 09/11] virtio-serial: Consolidate guest_open/guest_close into set_guest_connected Hans de Goede
2013-03-26 10:08 ` [Qemu-devel] [PATCH 10/11] virtio-serial: propagate guest_connected to the port on post_load Hans de Goede
2013-03-26 10:08 ` [Qemu-devel] [PATCH 11/11] spice-qemu-char: Drop hackish vmc_register on spice_chr_write Hans de Goede
2013-03-26 14:35 ` [Qemu-devel] [PATCH 0/11] chardev frontend open handling cleanup v2 Eric Blake
2013-03-27 21:15 ` Anthony Liguori
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=5151A78D.5010708@redhat.com \
--to=pbonzini@redhat.com \
--cc=amit.shah@redhat.com \
--cc=hdegoede@redhat.com \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
/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: link
Be 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).