qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] qom: add object_property_is_set


From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH] qom: add object_property_is_set
Date: Wed, 19 Feb 2014 09:11:36 +0200

On Tue, 2014-02-18 at 18:49 +0100, Andreas Färber wrote:
> Am 18.02.2014 18:26, schrieb Paolo Bonzini:
> > Il 18/02/2014 18:11, Marcel Apfelbaum ha scritto:
> >> It is used to replace qemu_opt_get_bool that provides a
> >> parameter for a default value. In this case we need to
> >> differentiate "no value" from "false."
> > 
> > But what would the getter return in that case?  If possible, it's better
> > to initialize to the default value in an instance_init method.
> 
> Another issue I see is that it's currently a valid use case to use a
> setter in instance_init to set default values. Doing so would flag the
> property as set with this patch.
Hi Andreas, thank you for the review!

As I replayed to Paolo, this does not contradict the patch's aim.
Meaning, if you have a default for all cases, is ok to init it and make
it "set". The interesting case is if you have 2 places: one that you want
the value to be "x" if is not set, and other place that you need "y" if
is not set.

> 
> To me it sounded like a concept similar to component-oriented IDEs where
> non-default values are shown in bold. We'd need a QMP API for that
> however, and we'd need to reset properties in instance_post_init to
> unset then (globals would be considered unset in that case).
I thought about it, but it seemed to me over-engineering *for my case*,
where all I need to know if the user supplied the value or not,
not need to "unset" it.

> 
> Another aspect is that dynamic properties are slightly awkward, if we
> think of setting the rtc, which then advances and reads back differently.
Sadly I am not familiar with the "rtc", but as I explained before,
I don't need the "repeatedly set/unset" use-case.

Thanks,
Marcel
   
> 
> Regards,
> Andreas
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]