On Wed, Feb 16, 2011 at 11:51 AM, Markus Armbruster <arm...@redhat.com> wrote: > Blue Swirl <blauwir...@gmail.com> writes: > >> On Tue, Feb 15, 2011 at 12:07 PM, Markus Armbruster <arm...@redhat.com> >> wrote: >>> Anthony Liguori <anth...@codemonkey.ws> writes: >>> >>>> On 02/12/2011 11:03 AM, Markus Armbruster wrote: >>>>> Blue Swirl<blauwir...@gmail.com> writes: >>>>> >>>>> >>>>>> Convert to qdev, also add a proper reset function. >>> [...] >>>>> Pointer properties are for dirty hacks only. Is there really no better >>>>> solution? Why does it have to be a property? >>>>> >>>> >>>> vmmouse is really just an extension to the PS2 Mouse. It's definitely >>>> not an ISA device. >>>> >>>> In terms of qdev enablement, I would just make it a boolean option to >>>> the PS2Mouse and not expose it as a top level device at all. It >>>> cannot exist without a PS2Mouse. >>> >>> Which means making it a separate qdev is wrong. That wrongness gave >>> rise to the dirty pointer property. Pointer property serves as canary >>> again. >>> >>> What now? >> >> I don't find pointer property use so dirty, > > See commit 036f7166. > >> but I'll try to combine >> the devices to see whether that makes sense. > > Appreciated.
The attached patch would merge the devices, but I'm not so sure this is the right approach. Merging seems to be OK, the registration could be removed harder by adding a switch for known vmport values. But vmmouse couldn't be left out of the build anymore since it would be built per target (because of CPUState dependencies). That would be a step backwards. Perhaps the register access helpers should be pushed to board level.
0001-Merge-vmmouse-and-vmport.patch
Description: application/mbox
