From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39616 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkUwp-0005UE-Cu for qemu-devel@nongnu.org; Wed, 02 Feb 2011 00:08:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkUwd-0007DB-2M for qemu-devel@nongnu.org; Wed, 02 Feb 2011 00:07:56 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:47266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkUwc-0007Co-U6 for qemu-devel@nongnu.org; Wed, 02 Feb 2011 00:07:55 -0500 Received: by pzk2 with SMTP id 2so1398374pzk.4 for ; Tue, 01 Feb 2011 21:07:53 -0800 (PST) Message-ID: <4D48E6A4.5030607@gmail.com> Date: Tue, 01 Feb 2011 22:07:48 -0700 From: David Ahern MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 0/4] fix/add CONFIG_* options for VMWare device emulation References: <1296579203-21083-1-git-send-email-ehabkost@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com, Blue Swirl Cc: Eduardo Habkost , qemu-devel@nongnu.org On 02/01/11 20:01, Juan Quintela wrote: > Blue Swirl wrote: >> On Tue, Feb 1, 2011 at 4:53 PM, Eduardo Habkost 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. > >