From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3nhr-0004j9-EL for qemu-devel@nongnu.org; Mon, 07 Nov 2016 12:27:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c3nhm-0008WB-IB for qemu-devel@nongnu.org; Mon, 07 Nov 2016 12:27:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58588) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c3nhm-0008Vt-A1 for qemu-devel@nongnu.org; Mon, 07 Nov 2016 12:27:34 -0500 Date: Mon, 7 Nov 2016 15:27:31 -0200 From: Eduardo Habkost Message-ID: <20161107172731.GS5057@thinpad.lan.raisama.net> References: <1477705687-31175-1-git-send-email-ehabkost@redhat.com> <1477705687-31175-8-git-send-email-ehabkost@redhat.com> <14edf10a-a961-3216-2cbb-c839ce913725@linux.vnet.ibm.com> <20161107130556.GQ5057@thinpad.lan.raisama.net> <9ad4d662-df82-06d0-52a2-ec92b34b9733@linux.vnet.ibm.com> <20161107150153.GB15102@redhat.com> <87oa1rp9sy.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87oa1rp9sy.fsf@dusky.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH v4 7/8] qmp: Support abstract classes on device-list-properties List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: "Daniel P. Berrange" , Halil Pasic , Igor Mammedov , Andreas =?iso-8859-1?Q?F=E4rber?= , qemu-devel@nongnu.org On Mon, Nov 07, 2016 at 04:51:57PM +0100, Markus Armbruster wrote: > "Daniel P. Berrange" writes: > > > On Mon, Nov 07, 2016 at 03:48:49PM +0100, Halil Pasic wrote: > >> > >> > >> On 11/07/2016 02:05 PM, Eduardo Habkost wrote: > >> > If you want some subclasses to not have the property, then I > >> > recommend not registering it as a class property on the base > >> > class in the first place. I don't expect to see a mechanism to > >> > allow subclasses to remove or override class properties from > >> > parent classes. > >> > > >> > >> Thank you very much for your reply. > >> > >> I understand, yet I see potential problems. The example with ioeventfd > >> and vhost in virtio-pci is a good one also because the first there was > >> the ioeventfd property with commit 653ced07 and then the vhost case came > >> along with commit 50787628ee3 (ok ioeventfd is not there for some non > >> vhost virtio-pci devices for reasons I do not understand). > >> > >> To rephrase this in generic context a specialization for which a > >> property does not make sense might come along after the property at the > >> base class was established. > >> > >> Now AFAIU properties are external API, so having to make a compatibility > >> breaking change there might not be fun. Does this mean one should be > >> very careful to put only use class level properties on abstract classes > >> where its certain that the property always makes sense including it's > >> access control? > > > > This could be an argument for *NOT* allowing introspectiing of properties > > against abstract parent classes. If you only ever allow introspecting against > > leaf node non-abstract classes, then QEMU retains the freedom to move props > > from a base class down to an leaf class without risk of breaking mgmt apps. > > That's a really good point. To generalize it a bit, introspection of > actual interfaces is fine, but permitting introspection of how they are > made can add artificial constraints. > > Introspecting the subtype relation is already problematic in this view. Yes, that's a very good point. But note that that this means making things more complex for libvirt. In the case of -cpu, if we don't expose (or allow libvirt to making assumptions about) subtype relations, the only way libvirt can conclude that "+foo can be used as -cpu option with any CPU model", is to query each and every CPU model type, and see if all of them support the "foo" property. It's a trade-off between an interface that's more complex to use and having less freedom to change the class hierarchy. Personally, I don't mind going either way, if we have a good reason for that. -- Eduardo