qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 0/4] fix/add CONFIG_* options for VMWare dev


From: David Ahern
Subject: Re: [Qemu-devel] Re: [PATCH 0/4] fix/add CONFIG_* options for VMWare device emulation
Date: Tue, 01 Feb 2011 22:07:48 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Thunderbird/3.1.7


On 02/01/11 20:01, Juan Quintela wrote:
> Blue Swirl <address@hidden> wrote:
>> On Tue, Feb 1, 2011 at 4:53 PM, Eduardo Habkost <address@hidden> wrote:
>>> Hi,
>>>
>>> This series makes CONFIG_VMWARE_VGA actually work (today we can't disable 
>>> the
>>> option without getting a build error).
>>>
>>> It also add two new options: CONFIG_VMMOUSE and CONFIG_VMPORT, for vmmouse.o
>>> and vmport.o.
>>
>> Nack, see the list archives for the discussion.
>>
>> One way to solve this which would preserve the device model would be
>> to add stub devices. For example, hw/vmmouse-stub.c would be:
>> void *vmmouse_init(void *m)
>> {
>>     return NULL;
>> }
> 
> I read the archives, and I still think that this is a stop backwards.  I
> was (one of the much) proposing the feature.
> 
> If this features is requested each 3 months for different people, could
> it be that really, really, our device model is not good enough?
> 
> We have three config files:
> - config-host.mak
> - config-target.mak
> - config-devices.mak
> 
> First two have a .h associated file, last one don't have it. And people
> is requesting it each 3 months.

And that's what I was going after a couple of weeks ago with
  http://www.mail-archive.com/address@hidden/msg51779.html

A small change to get the current design at least usable by adding the
device configs to the existing header files.

I understand the desire for a proper config architecture, but it is not
happening. Meanwhile people continue to try to use the existing broken
design, tripping over the same problems.

Massive changes in the wrong direction are thing;  resisting 2 liners
around init functions (#ifdef ... #endif) which fall in line with
existing code is a bit idealistic and not benefiting anyone.

David


> 
> 
> Later, Juan.
> 
> 



reply via email to

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