From: David Ahern <dsahern@gmail.com>
To: quintela@redhat.com, Blue Swirl <blauwirbel@gmail.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>, qemu-devel@nongnu.org
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 [thread overview]
Message-ID: <4D48E6A4.5030607@gmail.com> (raw)
In-Reply-To: <m3pqrb9m21.fsf@trasno.org>
On 02/01/11 20:01, Juan Quintela wrote:
> Blue Swirl <blauwirbel@gmail.com> wrote:
>> On Tue, Feb 1, 2011 at 4:53 PM, Eduardo Habkost <ehabkost@redhat.com> 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/qemu-devel@nongnu.org/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.
>
>
next prev parent reply other threads:[~2011-02-02 5:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-01 16:53 [Qemu-devel] [PATCH 0/4] fix/add CONFIG_* options for VMWare device emulation Eduardo Habkost
2011-02-01 16:53 ` [Qemu-devel] [PATCH 1/4] Add config-devices.h again Eduardo Habkost
2011-02-01 18:14 ` Stefan Weil
2011-02-02 18:09 ` Eduardo Habkost
2011-02-04 14:48 ` [Qemu-devel] " Juan Quintela
2011-02-01 16:53 ` [Qemu-devel] [PATCH 2/4] skip pci_vmsvga_init() calls if CONFIG_VMWARE_VGA is disabled Eduardo Habkost
2011-02-01 16:53 ` [Qemu-devel] [PATCH 3/4] add CONFIG_VMMOUSE option Eduardo Habkost
2011-02-01 16:53 ` [Qemu-devel] [PATCH 4/4] add CONFIG_VMPORT option Eduardo Habkost
2011-02-01 18:10 ` [Qemu-devel] [PATCH 0/4] fix/add CONFIG_* options for VMWare device emulation Blue Swirl
2011-02-02 3:01 ` [Qemu-devel] " Juan Quintela
2011-02-02 5:07 ` David Ahern [this message]
2011-02-02 7:55 ` Paolo Bonzini
2011-02-02 17:16 ` Blue Swirl
2011-02-02 17:37 ` Eduardo Habkost
2011-02-02 18:30 ` Blue Swirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D48E6A4.5030607@gmail.com \
--to=dsahern@gmail.com \
--cc=blauwirbel@gmail.com \
--cc=ehabkost@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).