Re: [Qemu-devel] How do we do user input bitmap properties?

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Dave Martin (Dave.Martin@arm.com) wrote:
> On Wed, May 15, 2019 at 09:15:20AM +0100, Andrew Jones wrote:
> > On Tue, May 14, 2019 at 03:32:13PM +0200, Markus Armbruster wrote:
> > > Syntax that can support such growth would be nice.
> > > 
> > > To grow a single unsigned number, we can make it wider (but we don't
> > > have infrastructure for numbers wider than 64 bits), or we can add more
> > > numbers (but under what name?).
> > > 
> > > Dotted keys syntax could grow more easily, but it's rather awkward.
> > > 
> > > Looking more closely at your "[PATCH 11/13] target/arm/cpu64: max cpu:
> > > Introduce sve-vls-map"... your syntax reflects your data structure:
> > > property "sve-vls-map" is of type uint64_t, and interpreted as bit set.
> > > This data type would have to grow, too.
> > > 
> > > We could make widen the integer property (but we don't have
> > > infrastructure for integer properties wider than 64 bits), or we can
> > > turn it into an array of integers (compatibility?), or we can add more
> > > properties to hold the additional integers (yet another silly way to
> > > represent a list/array of integers).
> > > 
> > > I'm not asking you to complicate things just to future-proof this.  Just
> > > pause and think whether you can pick a data type that's similarly
> > > convenient now, and easier to grow.
> > > 
> > > Then pick an external syntax for this data type.  You may have to pick a
> > > reasonable compromise between ease of implementation and ease of use.
> > 
> > Widening the integer property sounds good to me. I just hadn't thought of
> > it (implementation tunnel vision affecting my user interface design).
> > Andrea also mentioned that as a possibility in a reply to the series. I
> > think we can leave the property as a uint64_t right now and then, when/if
> > it needs to expand past 64 bits we can change the property to a string
> > and start parsing arbitrarily large integers from it. The internal state,
> > 'uint64_t sve_vls_map' can easily be changed to a 'uint64_t sve_vls_map[]'
> > at that point too. How's that sound?
> 
> Having an arbitrary-width integer should work.
> 
> It will suck a bit for the common case of sparse vector length support
> 
> 	0x8000000000000000800000008000808b
> 
> (= [ 1, 2, 4, 8, 16, 32, 64, 128 ] quadwords)

You could allow _'s as a readability feature just to allow you to see
boundaries.

	0x8000_0000_0000_0000_8000_0000_8000_808b

(Some might suggest IPv6 address syntax but I could never read that).

Dave

--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK