qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/6] QOM'ify hw/char devices


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v2 0/6] QOM'ify hw/char devices
Date: Fri, 06 May 2016 09:37:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Peter Maydell <address@hidden> writes:

> On 5 May 2016 at 11:38, 赵小强 <address@hidden> wrote:
>> At 2016-03-29 15:47:19, "xiaoqiang zhao" <address@hidden> wrote:
>>>This patch set trys to QOM'ify hw/char files, see commit messages
>>>for more details
>>>
>>>Changes in v2:
>>>* rename TYPE_SCLP_LM_CONSOLE to TYPE_SCLPLM_CONSOLE which is suggested by
>>>  Cornelia Huck <address@hidden>
>>>* rebase on the current master
>>>
>>>xiaoqiang zhao (6):
>>>  hw/char: QOM'ify escc.c
>>>  hw/char: QOM'ify etraxfs_ser.c
>>>  hw/char: QOM'ify lm32_juart.c
>>>  hw/char: QOM'ify lm32_uart.c
>>>  hw/char: QOM'ify sclpconsole-lm.c
>>>  hw/char: QOM'ify sclpconsole.c
>>>
>>> hw/char/escc.c           | 12 +++++-------
>>> hw/char/etraxfs_ser.c    | 11 +++++------
>>> hw/char/lm32_juart.c     |  9 +++------
>>> hw/char/lm32_uart.c      | 12 +++++-------
>>> hw/char/sclpconsole-lm.c | 14 +++++++++-----
>>> hw/char/sclpconsole.c    | 12 ++++++++----
>>> 6 files changed, 35 insertions(+), 35 deletions(-)
>>>
>>>--
>>>2.1.4
>>>
>>
>> ping ???
>
> I think you will have better luck if you rearrange all these
> QOM patches so that you provide them as one series per board
> or per target architecture, not one per type of device.
> There is no single person with responsibility for "all of
> hw/char" so structuring your cleanup patchsets like this will
> tend to result in the people who might care about the devices
> not looking at them. (Also you can concentrate on the devices
> which are actively maintained, like ARM ones, x86 ones, MIPS
> and SPARC ones, rather than the oddballs semi-orphaned ones
> like lm32, CRIS, etc.)

But please don't throw away your cleanups for the oddballs just yet.
Unloved code keeping obsolete internal interfaces alive is a problem
worth reducing.



reply via email to

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