aboutsummaryrefslogtreecommitdiff
path: root/chardev/char-fe.c
AgeCommit message (Collapse)Author
2019-02-13char: update the mux handlers in class callbackMarc-André Lureau
Instead of handling mux chardev in a special way in qemu_chr_fe_set_handlers(), we may use the chr_update_read_handler class callback instead. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20190206174328.9736-2-marcandre.lureau@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
2019-02-12chardev: fix mess in OPENED/CLOSED events when muxedArtem Pisarenko
When chardev is multiplexed (mux=on) there are a lot of cases where CHR_EVENT_OPENED/CHR_EVENT_CLOSED events pairing (expected from frontend side) is broken. There are either generation of multiple repeated or extra CHR_EVENT_OPENED events, or CHR_EVENT_CLOSED just isn't generated at all. This is mostly because 'qemu_chr_fe_set_handlers()' function makes its own (and often wrong) implicit decision on updated frontend state and invokes 'fd_event' callback with 'CHR_EVENT_OPENED'. And even worse, it doesn't do symmetric action in opposite direction, as someone may expect (i.e. it doesn't invoke previously set 'fd_event' with 'CHR_EVENT_CLOSED'). Muxed chardev uses trick by calling this function again to replace callback handlers with its own ones, but it doesn't account for such side effect. Fix that using extended version of this function with added argument for disabling side effect and keep original function for compatibility with lots of frontends already using this interface and being "tolerant" to its side effects. One more source of event duplication is just line of code in char-mux.c, which does far more than comment above says (obvious fix). Signed-off-by: Artem Pisarenko <artem.k.pisarenko@gmail.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <7dde6abbd21682857f8294644013173c0b9949b3.1541507990.git.artem.k.pisarenko@gmail.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2018-10-03chardev: unref if underlying chardev has no parentMarc-André Lureau
It's possible to write code creating a chardev backend that is not registered. When it is not user-created, it makes sense to keep it hidden. Let the associated frontend destroy it also in this case. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2018-10-03chardev: remove qemu_chr_fe_read_all() counterMarc-André Lureau
There is no obvious reason to have a loop counter. This limits from reading several megabytes large buffers in one go, since socket read/write usually have a limit. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-26chardev/char-fe: Allow NULL chardev in qemu_chr_fe_init()Peter Maydell
All the functions in char-fe.c handle the CharBackend having a NULL Chardev pointer, which means that the backend exists but is not connected to anything. The exception is qemu_chr_fe_init(), which will crash if passed a NULL Chardev pointer argument. This can happen for various boards if they're started with 'nodefaults': arm-softmmu/qemu-system-arm -S -nodefaults -M cubieboard riscv32-softmmu/qemu-system-riscv32 -nodefaults -M sifive_e Make qemu_chr_fe_init() accept a NULL chardev. This allows UART models to handle NULL chardev properties without generally needing to special case them or to manually create a NullChardev. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20180323152948.27048-1-peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-02Include less of the generated modular QAPI headersMarkus Armbruster
In my "build everything" tree, a change to the types in qapi-schema.json triggers a recompile of about 4800 out of 5100 objects. The previous commit split up qmp-commands.h, qmp-event.h, qmp-visit.h, qapi-types.h. Each of these headers still includes all its shards. Reduce compile time by including just the shards we actually need. To illustrate the benefits: adding a type to qapi/migration.json now recompiles some 2300 instead of 4800 objects. The next commit will improve it further. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180211093607.27351-24-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> [eblake: rebase to master] Signed-off-by: Eric Blake <eblake@redhat.com>
2018-03-02Include qapi/qmp/qerror.h exactly where neededMarkus Armbruster
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20180211093607.27351-2-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com>
2018-01-12chardev: use backend chr context when watch for fePeter Xu
In commit 6bbb6c0644 ("chardev: use per-dev context for io_add_watch_poll", 2017-09-22) all the chardev watches are converted to use per-chardev gcontext to support chardev to be run outside default main thread. However that's still missing one call from the frontend code. Touch that up. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20180104141835.17987-2-peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-09-22chardev: new qemu_chr_be_update_read_handlers()Peter Xu
Add a wrapper for the chr_update_read_handler(). Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1505975754-21555-2-git-send-email-peterx@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-07-14char: avoid chardevice direct accessAnton Nefedov
frontends should avoid accessing CharDriver struct where possible Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1499342940-56739-6-git-send-email-anton.nefedov@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-07-14char: forbid direct chardevice access for hotswap devicesAnton Nefedov
qemu_chr_fe_get_driver() is unsafe, frontends with hotswap support should not access CharDriver ptr directly as CharDriver might change. Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1499342940-56739-5-git-send-email-anton.nefedov@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-07-14char: add backend hotswap handlerAnton Nefedov
Frontends should have an interface to setup the handler of a backend change. The interface will be used in the next commits Signed-off-by: Anton Nefedov <anton.nefedov@virtuozzo.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <1499342940-56739-3-git-send-email-anton.nefedov@virtuozzo.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-06-02char: make chr_fe_deinit() optionaly delete backendMarc-André Lureau
This simplifies removing a backend for a frontend user (no need to retrieve the associated driver and separate delete call etc). NB: many frontends have questionable handling of ending a chardev. They should probably delete the backend to prevent broken reusage. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-06-02char: move CharBackend handling in char-fe unitMarc-André Lureau
Move all the frontend struct and methods to a seperate unit. This avoids accidentally mixing backend and frontend calls, and helps with readabilty. Make qemu_chr_replay() a macro shared by both char and char-fe. Export qemu_chr_write(), and use a macro for qemu_chr_write_all() (nb: yes, CharBackend is for char frontend :) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>