From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54190) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2FFZ-0000MN-0H for qemu-devel@nongnu.org; Wed, 02 Jul 2014 03:46:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2FFS-0006Em-UA for qemu-devel@nongnu.org; Wed, 02 Jul 2014 03:46:40 -0400 Message-ID: <53B3B8D8.507@suse.de> Date: Wed, 02 Jul 2014 09:46:32 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1404251378-5242-1-git-send-email-agraf@suse.de> <1404251378-5242-3-git-send-email-agraf@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/6] qom: Allow to make integer qom properties writeable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , Eric Auger , "qemu-devel@nongnu.org Developers" , qemu-ppc Mailing List , "Stalley, Sean" , Paolo Bonzini , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 02.07.14 05:48, Peter Crosthwaite wrote: > On Wed, Jul 2, 2014 at 7:49 AM, Alexander Graf 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