[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] How do we do user input bitmap properties?
From: |
Dave Martin |
Subject: |
Re: [Qemu-devel] How do we do user input bitmap properties? |
Date: |
Wed, 15 May 2019 11:53:55 +0100 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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)
Since lengths above 16 quadwords remain theoretical for now though it's
probably OK as a compromise, though.
The most human-compatible approach would be some kind of list
comprehension syntax, but it's hard to justify that adding a whole new
syntax is justified at this point.
[...]
Cheers
---Dave
- Re: [Qemu-devel] How do we do user input bitmap properties?, Andrew Jones, 2019/05/13
- Re: [Qemu-devel] How do we do user input bitmap properties?, Igor Mammedov, 2019/05/14
- Re: [Qemu-devel] How do we do user input bitmap properties?, Andrew Jones, 2019/05/15
- Re: [Qemu-devel] How do we do user input bitmap properties?, Igor Mammedov, 2019/05/15
- Re: [Qemu-devel] How do we do user input bitmap properties?, Andrew Jones, 2019/05/15
- Re: [Qemu-devel] How do we do user input bitmap properties?, Andrea Bolognani, 2019/05/23
- Re: [Qemu-devel] How do we do user input bitmap properties?, Eduardo Habkost, 2019/05/24
- Re: [Qemu-devel] How do we do user input bitmap properties?, Andrea Bolognani, 2019/05/27
- Re: [Qemu-devel] How do we do user input bitmap properties?, Eduardo Habkost, 2019/05/27
- Re: [Qemu-devel] How do we do user input bitmap properties?, Dave Martin, 2019/05/15