qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] hw/bt: drop bluetooth keyboard emulation.


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] hw/bt: drop bluetooth keyboard emulation.
Date: Mon, 12 Nov 2018 15:47:57 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Peter Maydell <address@hidden> writes:

> On 12 November 2018 at 09:16, Markus Armbruster <address@hidden> wrote:
>> Peter Maydell <address@hidden> writes:
>>
>>> On 9 November 2018 at 14:14, Gerd Hoffmann <address@hidden> wrote:
>>>> Broken (segfaultson first keypress) and appearently unused.
>>>>
>>>> Signed-off-by: Gerd Hoffmann <address@hidden>
>>
>> Please show the reproducer in the commit message.  Stack backtrace
>> wouldn't hurt.
>>
>>>> ---
>>>>  include/hw/bt.h     |   3 -
>>>>  hw/bt/hid.c         | 554 
>>>> ----------------------------------------------------
>>>>  vl.c                |  34 +---
>>>>  hw/bt/Makefile.objs |   3 +-
>>>>  qemu-options.hx     |   9 -
>>>>  5 files changed, 2 insertions(+), 601 deletions(-)
>>>>  delete mode 100644 hw/bt/hid.c
>>>
>>> Are we definitely happy that all the use cases for
>>> this code segfault, not just the one you tested ?
>>
>> Are there any others?
>>
>>> Does it cost us much to mark this deprecated in 3.1
>>> and drop it in 4.0 ?
>>
>> The cost is offering a known-to-be-broken option to users.
>>
>> The other half of the tradeoff: what would it gain us?
>
> My point is that we do not know it to be broken. We know that
> it has one bug, in the command line and segfault that Gerd
> found. I haven't seen anybody say they've done a check of
> all the use cases of this code and confirmed that all of them
> must pass through the codepath/situation that segfaults.

There's just one way to create a Bluetooth keyboard device.  It has just
one configuration knob: the Bluetooh "vlan".  This leads me to believe
there's no way to create this device that doesn't crash.  Regardless,
asking Gerd to confirm is fair.  Preferably in the commit message of v2.

> What it gains us is that we get to be sure that we are keeping
> our promise with our users that we don't just randomly remove
> features they were using without notice.

No gain unless there is a way to use it.



reply via email to

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