qemu-stable
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-stable] [Qemu-devel] [PATCH] mux: fix ctrl-a b again


From: Marc-André Lureau
Subject: Re: [Qemu-stable] [Qemu-devel] [PATCH] mux: fix ctrl-a b again
Date: Wed, 18 Apr 2018 12:36:43 +0200

Hi

On Tue, Apr 17, 2018 at 8:36 PM, Philippe Mathieu-Daudé <address@hidden> wrote:
> Hi,
>
>>>> On 16 April 2018 at 19:18, Marc-André Lureau
>>>> <address@hidden> wrote:
>>>>> Commit fb5e19d2e1472e96d72d5e4d89c20033f8ab345c originally fixed the
>>>>> regression, but was inadvertently broken again in merge commit
>>>>> 2d6752d38d8acda.
>>>>>
>>>>> Fixes:
>>>>> https://bugs.launchpad.net/qemu/+bug/1654137
>>>>>
>>>>> Cc: address@hidden
>>>>> Signed-off-by: Marc-André Lureau <address@hidden>
>>>>> ---
>>>>>  chardev/char-mux.c | 1 +
>>>>>  1 file changed, 1 insertion(+)
>>>>>
>>>>> diff --git a/chardev/char-mux.c b/chardev/char-mux.c
>>>>> index 1b925c8dec..6055e76293 100644
>>>>> --- a/chardev/char-mux.c
>>>>> +++ b/chardev/char-mux.c
>>>>> @@ -304,6 +304,7 @@ void mux_set_focus(Chardev *chr, int focus)
>>>>>      }
>>>>>
>>>>>      d->focus = focus;
>>>>> +    chr->be = d->backends[focus];
>>>>>      mux_chr_send_event(d, d->focus, CHR_EVENT_MUX_IN);
>>>>>  }
>>>>>
>>>>> --
>>>>> 2.17.0.rc1.36.gcedb63ea2f
>>>>
>>>> Opinions welcome on whether this is a regression fix worth
>>>> putting into rc4.
>>>
>>> It is a regression, but a long standing one - we've been broken for quite
>>> a while since 2.9.0 or even before.
>>>
>>> If we're doing an rc4 anyway I'd suggest including it, but not the end of
>>> the world if it has to go in via -stable given how long we've been broken
>>> for.
>>>
>>
>> Thanks for the clarification; I've applied this to master.
>
> Since this commit, the console on the Malta board stay black...
>
> Before:
> $ qemu-system-mips -M malta -m 512 \
>   -kernel vmlinux-3.2.0-4-4kc-malta -append 'root=/dev/sda1' \
>   -nographic
> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.2.0-4-4kc-malta
> (address@hidden) (gcc version 4.6.3 (Debian 4.6.3-14) )
> #1 Debian 3.2.51-1
> [    0.000000] Config serial console: console=ttyS0,38400n8r
> [    0.000000] bootconsole [early0] enabled
> ...
>
> After:
> $ qemu-system-mips -M malta -m 512 \
>   -kernel vmlinux-3.2.0-4-4kc-malta -append 'root=/dev/sda1' \
>   -nographic
> QEMU 2.11.92 monitor - type 'help' for more information
> (qemu) QEMU 2.11.92 monitor - type 'help' for more information
> (qemu) q
>

In  commit cd9526ab7c04f2c32c63340b04401f6ed25682b9
Author: Philippe Mathieu-Daudé <address@hidden>
Date:   Thu Mar 8 23:39:32 2018 +0100

    hw/isa/superio: Factor out the serial code from pc87312.c

You changed from:

-            if (chr == NULL) {
-                snprintf(name, sizeof(name), "ser%d", i);
-                chr = qemu_chr_new(name, "null");
-            }

to:

+            if (chr == NULL || chr->be) {
+                name = g_strdup_printf("discarding-serial%d", i);
+                chr = qemu_chr_new(name, "null");
+            } else {
+                name = g_strdup_printf("serial%d", i);
+            }

Why do you check if chr->be ? In case of a mux chardev, it may already
have an active frontend (yeah be is CharBackend which is the frontend,
I still can't grasp that either, please Paolo change your mind! ;).
And this is the job for a mux chardev, handling several frontends.

Furthermore, there is a better API for checking the limit of a
chardev: qemu_chr_is_busy(). Accessing char/fe internal structure
should warn you something could be done better.

> 1b2503fcf7b5932c5a3779ca2ceb92bd403c4ee7 is the first bad commit
> Author: Marc-André Lureau <address@hidden>
> Date:   Mon Apr 16 20:18:44 2018 +0200
>
>     mux: fix ctrl-a b again
>
>     Commit fb5e19d2e1472e96d72d5e4d89c20033f8ab345c originally fixed the
>     regression, but was inadvertently broken again in merge commit
>     2d6752d38d8acda.
>
>     Fixes:
>     https://bugs.launchpad.net/qemu/+bug/1654137
>



-- 
Marc-André Lureau



reply via email to

[Prev in Thread] Current Thread [Next in Thread]