qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 06/10] vmmouse: convert to qdev


From: Blue Swirl
Subject: [Qemu-devel] Re: [PATCH 06/10] vmmouse: convert to qdev
Date: Fri, 18 Feb 2011 20:04:47 +0200

On Fri, Feb 18, 2011 at 2:34 PM, Paolo Bonzini <address@hidden> wrote:
> On 02/17/2011 08:52 PM, Blue Swirl wrote:
>>
>> On Wed, Feb 16, 2011 at 11:51 AM, Markus Armbruster<address@hidden>
>>  wrote:
>>>
>>> Blue Swirl<address@hidden>  writes:
>>>
>>>> On Tue, Feb 15, 2011 at 12:07 PM, Markus Armbruster<address@hidden>
>>>>  wrote:
>>>>>
>>>>> Anthony Liguori<address@hidden>  writes:
>>>>>
>>>>>> On 02/12/2011 11:03 AM, Markus Armbruster wrote:
>>>>>>>
>>>>>>> Blue Swirl<address@hidden>    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.
>
> Is there any fundamental reason why obj-i386-$(CONFIG_VMMOUSE) doesn't work?

Hm, actually nothing. There just aren't such devices except fulong
ones. I'll make a new patch.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]