From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42506)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <marcel@redhat.com>) id 1YdEw4-0003Zd-IM
	for qemu-devel@nongnu.org; Wed, 01 Apr 2015 05:27:45 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <marcel@redhat.com>) id 1YdEw0-0007zA-7S
	for qemu-devel@nongnu.org; Wed, 01 Apr 2015 05:27:44 -0400
Received: from mx1.redhat.com ([209.132.183.28]:42923)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <marcel@redhat.com>) id 1YdEvz-0007ym-QD
	for qemu-devel@nongnu.org; Wed, 01 Apr 2015 05:27:40 -0400
Message-ID: <551BBA06.3020208@redhat.com>
Date: Wed, 01 Apr 2015 12:27:34 +0300
From: Marcel Apfelbaum <marcel@redhat.com>
MIME-Version: 1.0
References: <551AAD75.8090909@linux.vnet.ibm.com>
	<551B963E.9060800@gmail.com>	<551BA5D1.8050002@redhat.com>
	<87fv8kxmrh.fsf@blackfin.pond.sub.org>
	<551BB54A.9050700@redhat.com> <551BB6E7.4090003@redhat.com>
	<551BB8FA.9020803@redhat.com>
In-Reply-To: <551BB8FA.9020803@redhat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [qemu devel] disable shared memory is not
 available with this QEMU binary
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>, Markus Armbruster <armbru@redhat.com>
Cc: Tony Krowiak <akrowiak@linux.vnet.ibm.com>, qemu-devel@nongnu.org, =?windows-1252?Q?Andreas_F=E4rber?= <afaerber@suse.de>

On 04/01/2015 12:23 PM, Paolo Bonzini wrote:
>
>
> On 01/04/2015 11:14, Marcel Apfelbaum wrote:
>> This + 'monkey-patch' may be a feasible solution for 2.4
>
> Why monkey-patch and not just revert?
There are already several machine sub-types that have
their own options, some of the code I think
it was added after the 'dynamic options' patch, so revert will
not be enough.
We will need to go over the new options and add them to the global
list.

At this point, adding the machine options to the global list during
machine init seems to be a less risky and
will also keep options per machine.

Maybe I'll try it and see how it looks.

Thanks,
Marcel
>
> Paolo
>