Am 27.01.2012 13:41, schrieb Anthony Liguori: > On 01/27/2012 03:38 AM, Andreas Färber wrote: >> Am 27.01.2012 07:23, schrieb Stefan Hajnoczi: >>> On Tue, Jan 24, 2012 at 06:17:36PM +0100, Andreas Färber wrote: >>>> From: Andreas Färber<andreas.faer...@web.de> >>>> >>>> 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. >>>> >>>> Signed-off-by: Andreas Färber<andreas.faer...@web.de> >>>> Cc: Juan Quintela<quint...@redhat.com> >>>> Cc: Markus Armbruster<arm...@redhat.com> >>>> Cc: Jan Kiszka<jan.kis...@siemens.com> >>>> Cc: Vasilis Liaskovitis<vasilis.liaskovi...@profitbricks.com> >>>> --- >>>> v5 -> v6: >>> >>> Please merge through a qemu.git committer. v6 and discussion means this >>> isn't trivial. >> >> Unfortunately that hasn't happened for half a year though. Generally no >> qemu.git committer seems to care about cherry-picking useful >> infrastructures from bigger series even once discussions are resolved. > > So... why are we introducing a type that's not being used anywhere? > > Are you planning to use this type somewhere or is this purely speculative?
My ISA series and later the 40P series used it (therefore "cherry-picking" above; additionally it turned out recently that there had been confusion over who was supposed to pull for PReP - thanks for recently doing so btw). Now Jan and I agreed that Vasilis should reuse it for his series in place of uint32. Therefore I would've appreciated a quick merge (thus qemu-trivial) so that it can be rebased upon. Unfortunately I didn't have code for testing all paths handy, my bad. But nevertheless all these discussions never opposed the core idea, only the exact way things were printed or parsed. When using qdev_prop_set_bool() internally, like I did for the pc87312 Super I/O, none of this matters except for 'info qtree'. So if we could decide on the DEFINE_PROP_*() macro name, all of the parsing and printing can still be changed back and forth in a central place including when someone ventures to translate QEMU to non-English, then everything gets ugly anyway. :) Correct me if I'm wrong, but as far as I saw, your QOM series only moved this around and the qdev macros remained. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
