[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/4] virtio-serial: Clean up virtser_bus_dev_pri
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH 2/4] virtio-serial: Clean up virtser_bus_dev_print() output |
Date: |
Wed, 29 Jun 2011 11:22:07 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Andreas Färber <address@hidden> writes:
> Am 19.05.2011 um 16:18 schrieb Markus Armbruster:
>
>> Amit Shah <address@hidden> writes:
>>
>>> On (Thu) 19 May 2011 [13:37:15], Markus Armbruster wrote:
>>>> Old version looks like this in info qtree (last four lines):
>>>>
>>>> dev: virtconsole, id ""
>>>> dev-prop: is_console = 1
>>>> dev-prop: nr = 0
>>>> dev-prop: chardev = <null>
>>>> dev-prop: name = <null>
>>>> dev-prop-int: id: 0
>>>> dev-prop-int: guest_connected: 1
>>>> dev-prop-int: host_connected: 0
>>>> dev-prop-int: throttled: 0
>>>>
>>>> Indentation is off, and "dev-prop-int" suggests these are properties
>>>> you can configure with -device, which isn't the case. The other
>>>> buses' print_dev() callbacks don't do that. For instance, PCI's
>>>> output looks like this:
>>>>
>>>> class Ethernet controller, addr 00:03.0, pci id 1af4:1000
>>>> (sub 1af4:0001)
>>>> bar 0: i/o at 0xffffffffffffffff [0x1e]
>>>> bar 1: mem at 0xffffffffffffffff [0xffe]
>>>> bar 6: mem at 0xffffffffffffffff [0xfffe]
>>>>
>>>> Change virtser_bus_dev_print() to that style. Result:
>>>>
>>>> dev: virtconsole, id ""
>>>> dev-prop: is_console = 1
>>>> dev-prop: nr = 0
>>>> dev-prop: chardev = <null>
>>>> dev-prop: name = <null>
>>>> port 0, guest on, host off, throttle off
>>>
>>> Here the original guest_connected and host_connected meant whether
>>> the
>>> endpoints were open. guest on/off, host on/off don't convey that
>>> meaning. Can't think of a short version, can you?
>>
>> I chose on/off to stay consistent with how qdev shows bool properties
>> (print_bit() in qdev-properties.c). May be misguided. Like you, I'm
>> having difficulties coming up with a better version that is still
>> consise.
>
> Erm, I'm not aware that my qdev bool patch got committed yet, so the
> question of how to parse/print bool properties (on/off vs. yes/no) is
> still undecided, no comments so far.
No, there is precedence: PROP_TYPE_BIT's parse_bit(), print_bit(). The
fact that it's a bit within a uint32_t rather than bool is
implementation detail that shouldn't matter at the -device / info qtree
level.
> It would be entirely possible to
> let the author decide that on a case-by-case basis by using different
> property type enums for the same 'bool' type.
Possible, but is it wise?