From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45147) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbqyK-0007jM-Oc for qemu-devel@nongnu.org; Wed, 29 Jun 2011 05:22:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbqyI-00066P-W4 for qemu-devel@nongnu.org; Wed, 29 Jun 2011 05:22:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbqyI-00066E-H9 for qemu-devel@nongnu.org; Wed, 29 Jun 2011 05:22:10 -0400 From: Markus Armbruster References: <1305805037-17752-1-git-send-email-armbru@redhat.com> <1305805037-17752-3-git-send-email-armbru@redhat.com> <20110519131033.GA13222@amit-x200.redhat.com>

Date: Wed, 29 Jun 2011 11:22:07 +0200 In-Reply-To: ("Andreas =?utf-8?Q?F=C3=A4rber=22's?= message of "Mon, 27 Jun 2011 21:32:57 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/4] virtio-serial: Clean up virtser_bus_dev_print() output List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= Cc: Amit Shah , alevy@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com Andreas F=C3=A4rber writes: > Am 19.05.2011 um 16:18 schrieb Markus Armbruster: > >> Amit Shah 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 =3D 1 >>>> dev-prop: nr =3D 0 >>>> dev-prop: chardev =3D >>>> dev-prop: name =3D >>>> 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 =3D 1 >>>> dev-prop: nr =3D 0 >>>> dev-prop: chardev =3D >>>> dev-prop: name =3D >>>> 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?