On 28/07/2015 08:45, Pavel Fedin wrote:
> I can try to reengineer this and see what happens. If it works fine, will
> such rework be accepted? [*] expansion would still be slow, but we could
> deprecate it.
>
> I have just done a search of "[*]" across all *.c files, and here is what i
> ca
> > Also, i thought that there could be
> > some hard to notice problems, when, for example, we first add
> > unnamed-gpio-in[0...1023], then add another 1024 pins, where count
> > again goes from 0 to 1023. And we would get collision and failure,
> > unless we know, that we already have 1024 objec
On 27/07/2015 17:19, Pavel Fedin wrote:
>>> I'm just asking myself whether this is really necessary. Is the
>>> automagic [*] really needed in this case?
> In this particular case, perhaps, not. However, this automagic is
> used not only with GPIOs. It is used also with memory regions, as
> wel
Hello!
> I'm just asking myself whether this is really necessary. Is the
> automagic [*] really needed in this case?
In this particular case, perhaps, not. However, this automagic is used not
only with GPIOs. It is used also with memory regions, as well as with some
other places. Also, i t
On 27/07/2015 17:06, Paolo Bonzini wrote:
>
>
> On 27/07/2015 16:57, Andreas Färber wrote:
I am absolutely fine with absolutely anything. Suggest what you like and
i'll change it.
>> Paolo suggested ...-count on #qemu, but I would prefer ...-max or so, as
>> the number could differ
On 27/07/2015 16:57, Andreas Färber wrote:
>> > I am absolutely fine with absolutely anything. Suggest what you like and
>> > i'll change it.
> Paolo suggested ...-count on #qemu, but I would prefer ...-max or so, as
> the number could differ when some property gets deleted.
Yes, I agree -max
Hi,
Am 27.07.2015 um 16:36 schrieb Pavel Fedin:
>> Do we really want '#' in property names? Elsewhere, we require names to
>> be id_wellformed().
>
> I already asked this question to Andreas but got no single reply from him.
> My initial idea was to leave '[*]' as a suffix for this magic prope
Hello!
> IIUC, the performance problem with object_property_add is caused by
> the fact that every time we add a property we have to do a linear
> search over every existing property running strcmp to see if the
> new property already exists.
Yes, exactly. And this linear search gets extremely
Hello!
> Do we really want '#' in property names? Elsewhere, we require names to
> be id_wellformed().
I already asked this question to Andreas but got no single reply from him. My
initial idea was to leave '[*]' as a suffix for this magic property. He only
told that he doesn't like it.
I a
On 27/07/2015 15:23, Daniel P. Berrange wrote:
> It feels like a poor hack to deal with fact that we've not got support
> for setting non-scalar properties. Since we're representing arrays
> implicitly,
See http://lists.gnu.org/archive/html/qemu-devel/2014-10/msg00623.html:
--
"
On Mon, Jul 27, 2015 at 03:03:26PM +0200, Markus Armbruster wrote:
> Pavel Fedin writes:
>
> > Avoid repetitive lookup of every property in array starting from 0 by adding
> > one more property which caches last used index. Every time an array is
> > expanded the index is picked up from this cach
Pavel Fedin writes:
> Avoid repetitive lookup of every property in array starting from 0 by adding
> one more property which caches last used index. Every time an array is
> expanded the index is picked up from this cache.
>
> The property is a uint32_t and its name is name of the array plus '#'
On Tue, Jul 14, 2015 at 12:39:01PM +0300, Pavel Fedin wrote:
> Avoid repetitive lookup of every property in array starting from 0 by adding
> one more property which caches last used index. Every time an array is
> expanded the index is picked up from this cache.
>
> The property is a uint32_t and
Avoid repetitive lookup of every property in array starting from 0 by adding
one more property which caches last used index. Every time an array is
expanded the index is picked up from this cache.
The property is a uint32_t and its name is name of the array plus '#'
('name#'). It has getter functi
14 matches
Mail list logo
