From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NJItv-0001lE-A1 for qemu-devel@nongnu.org; Fri, 11 Dec 2009 22:44:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NJItq-0001ak-BE for qemu-devel@nongnu.org; Fri, 11 Dec 2009 22:44:10 -0500 Received: from [199.232.76.173] (port=53737 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJItp-0001aU-UA for qemu-devel@nongnu.org; Fri, 11 Dec 2009 22:44:05 -0500 Received: from mail-yw0-f179.google.com ([209.85.211.179]:34435) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NJItp-0005Xr-Ks for qemu-devel@nongnu.org; Fri, 11 Dec 2009 22:44:05 -0500 Received: by ywh9 with SMTP id 9so1470504ywh.19 for ; Fri, 11 Dec 2009 19:44:04 -0800 (PST) Message-ID: <4B231182.1080208@codemonkey.ws> Date: Fri, 11 Dec 2009 21:44:02 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Spice project is now open References: <1393046876.1549021260539141025.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> <4B226BFC.1040606@codemonkey.ws> <20091211204828.464707cf@redhat.com> <4B2297A2.8040102@codemonkey.ws> <20091211212135.645864f9@redhat.com> <4B229DCE.7070500@codemonkey.ws> <20091211213911.0dce90dc@redhat.com> <4B22A2D9.6020602@codemonkey.ws> <20091211223250.129675fc@redhat.com> <4B22B035.3010601@codemonkey.ws> <20091211233158.22e6681f@redhat.com> <4B22C093.2090806@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org Paolo Bonzini wrote: > On 12/11/2009 10:58 PM, Anthony Liguori wrote: >> The concerns have been 1) they will be abused with the introduction >> of proprietary plugins > > How so? A typical scenario is someone develops a closed source plugin, but does not distribute it with the original piece of software thinking that they aren't creating a derived work because there's no combination. But it's not necessary to get too tied up in this one. The later are more important. >> 2) we would have tremendous difficulty maintaining a stable plugin abi > > Then don't promise it. GCC doesn't for example. (And it solves > problem 1 too!...) GCC is not the best example since it's support for plugins are relatively new. It's bad for users. They start using a plugin for one version and they really like it, they want to update to a new version of the base program and now their plugin no longer works. The plugin has gone unmaintained and now they have to choose between the plugin and updating the base program. >> 3) they would create stability issues >> in qemu because the plugin quality cannot be controlled. > > How is this different from 3rd party modules in the kernel? I don't think the kernel is an example of it working smoothly. It's a constant source of frustration for users and people are constantly doing ugly things wrt licensing. Regards, Anthony Liguori