On Fri, 10 Feb 2017 19:27:21 +0100 Andreas Färber <afaer...@suse.de> wrote:
> Am 10.02.2017 um 19:18 schrieb Andrew Jones: > > On Fri, Feb 10, 2017 at 05:16:59PM +0100, Igor Mammedov wrote: > >> On Fri, 10 Feb 2017 17:31:33 +0200 > >> "Michael S. Tsirkin" <m...@redhat.com> wrote: > >> > >>> On Fri, Feb 10, 2017 at 11:12:13AM +0100, Laszlo Ersek wrote: > >>>> On 02/05/17 10:11, b...@skyportsystems.com wrote: > >>>>> From: Ben Warren <b...@skyportsystems.com> > >> [...] > >> > >>>> > >>>> - or else, add another boolean property to vmgenid, one that parallels > >>>> "dma-enabled" of "fw-cfg" precisely, in HW_COMPAT*. Then simply fail > >>>> realize() when this property is false. > >>> > >>> That's probably the easiest way. x-fw-cfg-dma-enabled. > >>> Won't delay merging because of this, can be done with > >>> patch on top. > >> (not related to this series) > >> > >> I've thought that there still were no consensus on x-foo prefix, > >> not to mention that x- might be legitimate prefix for some properties. > >> > >> Maybe we should add a flag to property like INTERNAL_PROPERTY > >> and then set it explicitly on for internal stuff. > >> > >> That way we could cleanly exclude internal properties from > >> -device foo,help and make sure that user won't set them from CLI. > >> I'd even volunteer to add this API to Object > > > > Yes, please. I know of a property or two where it would be nice to > > have that flag. > > Apart from documentation, what effect would such a flag have? > > With QOM I don't really see "internal" as being a thing: Besides -device > and the likes, we expose qom-set operation and -global option, and I > don't think it makes sense to restrict the latter two. For -device, > "realized" is a property I would classify as non-user maybe. I'd propose to start with this flag hiding/forbiding usage of property in following interfaces: * -device * -device foo,help * device_add With docs mentioning that usage of hidden properties with -globals/qom-set isn't recommended. > > Regards, > Andreas >
