From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46433) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpkeb-0000gr-QG for qemu-devel@nongnu.org; Tue, 24 Jan 2012 12:59:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpkeW-0006yc-41 for qemu-devel@nongnu.org; Tue, 24 Jan 2012 12:59:33 -0500 Message-ID: <4F1EF171.4030406@codemonkey.ws> Date: Tue, 24 Jan 2012 11:59:13 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1327425457-31313-1-git-send-email-afaerber@suse.de> <4F1EEA64.2080704@siemens.com> <4F1EEC88.8060803@suse.de> In-Reply-To: <4F1EEC88.8060803@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v6] qdev: Add support for property type bool List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: Kevin Wolf , Vasilis Liaskovitis , Anthony Liguori , Juan Quintela , "qemu-trivial@nongnu.org" , Jan Kiszka , Markus Armbruster , "qemu-devel@nongnu.org" , Blue Swirl , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , Amit Shah , Paolo Bonzini On 01/24/2012 11:38 AM, Andreas Färber wrote: > Am 24.01.2012 18:29, schrieb Jan Kiszka: >> On 2012-01-24 18:17, Andreas Färber wrote: >>> From: Andreas Färber >>> >>> VMState supports the type bool but qdev instead supports bit, backed by >>> uint32_t. Therefore let's add DEFINE_PROP_BOOL() and qdev_prop_set_bool(). >>> >>> bool by definition is either true or false. Should the need arise to >>> parse yes/no, on/off, 1/0 or whatever as well, we can still add that at >>> a later point in time. >> >> To make it a real replacement for PROP_TYPE_BIT, let's use on/off, also >> for printing. Not only programmers may use this interface. ;) > > Actually non-programmers are the reason for this: cache=on/off makes a > great deal of sense in English (noun), but not enabled=off (adjective), > which was my use case of this patch for ISA devices. > > I'm fine with accepting the whole range of possibilities for parsing. > For printing I see no reason to, since there's no legacy users of this > new type we could break. true/false seemed better than yes/no. > >>> +PropertyInfo qdev_prop_bool = { >>> + .name = "bool", >> >> Now we have "bool" and "boolean". Can we rename the latter to bit? > > I'd be fine with that, just don't know if that would break anything > elsewhere for qdev or QOM? Nothing breaks. Legacy properties (yes, these are legacy) will stick around until we stabilize the QOM public interface. I think that's probably 2.0 material. Regards, Anthony Liguori > > Andreas >