motorhead/qemu
1
0
Fork 0
mirror of https://github.com/Motorhead1991/qemu.git synced 2025-08-08 18:23:57 -06:00
Code Issues Projects Releases Packages Wiki Activity Actions

char: move front end handlers in CharBackend

Browse source 
Since the hanlders are associated with a CharBackend, rather than the
CharDriverState, it is more appropriate to store in CharBackend. This
avoids the handler copy dance in qemu_chr_fe_set_handlers() then
mux_chr_update_read_handler(), by storing the CharBackend pointer
directly.

Also a mux CharDriver should go through mux->backends[focused], since
chr->be will stay NULL. Before that, it was possible to call
chr->handler by mistake with surprising results, for ex through
qemu_chr_be_can_write(), which would result in calling the last set
handler front end, not the one with focus.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161022095318.17775-22-marcandre.lureau@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This commit is contained in:
Marc-André Lureau 2016-10-22 12:53:01 +03:00 • committed by Paolo Bonzini
parent ea3af47d75
commit a4afa548fc
4 changed files with 98 additions and 70 deletions
Download patch file Download diff file Expand all files Collapse all files

12
hw/bt/hci-csr.c
View file

@ -78,15 +78,17 @@ enum {
static inline void csrhci_fifo_wake(struct csrhci_s *s)
{
CharBackend *be = s->chr.be;
if (!s->enable || !s->out_len)
return;
/* XXX: Should wait for s->modem_state & CHR_TIOCM_RTS? */
if (s->chr.chr_can_read && s->chr.chr_can_read(s->chr.handler_opaque) &&
s->chr.chr_read) {
s->chr.chr_read(s->chr.handler_opaque,
s->outfifo + s->out_start ++, 1);
s->out_len --;
if (be && be->chr_can_read && be->chr_can_read(be->opaque) &&
be->chr_read) {
be->chr_read(be->opaque,
s->outfifo + s->out_start++, 1);
s->out_len--;
if (s->out_start >= s->out_size) {
s->out_start = 0;
s->out_size = FIFO_LEN;