Re: [Qemu-ppc] [Qemu-devel] [PATCH 2/6] qom: Allow to make integer qom properties writeable

[Alexander Graf]

On 02.07.14 05:48, Peter Crosthwaite wrote:
> On Wed, Jul 2, 2014 at 7:49 AM, Alexander Graf <address@hidden> wrote:
> > We have helper functions to easily expose integers as QOM object properties.
> > However, these are read only.
> I think this is a good idea, and _ptr properties should have some write-ability.
>
> > Let's introduce some easy helpers that would
> > just write to the values.
> >
> > We also add a new parameter to the property registration that allows us to
> > specify the setter function. If we need special magic to happen, we can make
> > it happen in our own setters. Otherwise we can just use one of the provided
> > helper setters that implement generic value writes for integers.
> >
> > With this we can easily create read-write qom variables, but maintain the
> > flexibility to diverge slightly from the default case.
> But I think it's inconsistent that the read path is automatic and
> write path required an open-coded callback to be added. If you need
> open-codedness then it can be achieved with just raw
> object_property_set. The real issue is that the other side (e.g. the
> read handler for a side-effected write) will need to be open coded too
> leading to mass boiler plate (is this the problem you are trying to
> solve?).

I was trying to think of a nice middle ground between flexibility that's 
needed and flexibility that's required. I think it's very common to have

  * read-only properties
  * read-write properties
  * read-write properties with special handling for the write path 
(checks mostly, boundary or permission)

> I think we can minimise the number of core QOM API use cases while
> achieving your goal by:
>
> 1: Leaving the _ptr APIs as minimal having no open-coded capability.
> 2: Adding global trivial getter and setter fns that can be passed to
> the lower level object_property_add.

That'd be an alternative approach - I would just open codedly call 
object_property_add with the global helpers then. I'm not sure that's 
incredibly nicer though.

In the code flow you describe above, a read-only accessor would be 
declared the same way it does today. Read-write ones would already have 
to go via object_property_add.

So we either add clumsy code in the actual user files (which we try to 
reduce) or we end up adding another set of _rw functions (which is what 
I did at first - it's ugly) or we add an enum as parameter (which I did 
then, but it's also ugly, see next email).

I'm not passionate about the approach I ended up taking, but I couldn't 
think of a better middle ground. If you are passionate about it though I 
can easily declare the getters public as well and just use 
object_property_add() explicitly.

> When one side of a property (either read or write) has a side effect,
> go open-coded (you can also call the trivial setter/getter from your
> open coded fn for the actual ptr read/write to avoid device code
> having to manage visitors). Then add the trivial setter/getter for the
> other side. LOC should be roughly the same as this soln.
>
> This also supports the rarer case of a property with read side effects
> (can't think of a use case yet but i sure it's out there).

Yeah, I can't really think of too many properties that really should 
have read side effects ;).


Alex