Hi,
On 10/10/19 8:53 PM, Dr. David Alan Gilbert wrote:
> * Auger Eric (eric.au...@redhat.com) wrote:
>> Hi peter,
>>
>> On 10/10/19 2:35 PM, Peter Xu wrote:
>>> On Thu, Oct 10, 2019 at 02:11:46PM +0200, Auger Eric wrote:
>>> Also, should we avoid using UINT in all cases? But of course if we
>
* Auger Eric (eric.au...@redhat.com) wrote:
> Hi peter,
>
> On 10/10/19 2:35 PM, Peter Xu wrote:
> > On Thu, Oct 10, 2019 at 02:11:46PM +0200, Auger Eric wrote:
> > Also, should we avoid using UINT in all cases? But of course if we
> > start to use VMSTATE_UINT32_V then we don't have this
Hi peter,
On 10/10/19 2:35 PM, Peter Xu wrote:
> On Thu, Oct 10, 2019 at 02:11:46PM +0200, Auger Eric wrote:
> Also, should we avoid using UINT in all cases? But of course if we
> start to use VMSTATE_UINT32_V then we don't have this issue.
Depending on the clarification of above poi
Hi Peter,
On 10/10/19 1:35 PM, Peter Xu wrote:
> On Thu, Oct 10, 2019 at 09:57:01AM +0200, Auger Eric wrote:
+static gboolean put_gtree_elem(gpointer key, gpointer value, gpointer
data)
+{
+struct put_gtree_data *capsule = (struct put_gtree_data *)data;
+QEMUFile
On Thu, Oct 10, 2019 at 02:11:46PM +0200, Auger Eric wrote:
> >>> Also, should we avoid using UINT in all cases? But of course if we
> >>> start to use VMSTATE_UINT32_V then we don't have this issue.
> >> Depending on the clarification of above point, maybe I can rename
> >> VMSTATE_GTREE_DIRECT_K
On Thu, Oct 10, 2019 at 09:57:01AM +0200, Auger Eric wrote:
> >> +static gboolean put_gtree_elem(gpointer key, gpointer value, gpointer
> >> data)
> >> +{
> >> +struct put_gtree_data *capsule = (struct put_gtree_data *)data;
> >> +QEMUFile *f = capsule->f;
> >> +int ret;
> >> +
> >> +
Hi Peter,
On 10/9/19 8:28 AM, Peter Xu wrote:
> On Fri, Oct 04, 2019 at 01:20:25PM +0200, Eric Auger wrote:
>> Introduce support for GTree migration. A custom save/restore
>> is implemented. Each item is made of a key and a data.
>>
>> If the key is a pointer to an object, 2 VMSDs are passed into
Hi Juan,
On 10/5/19 12:34 AM, Juan Quintela wrote:
> Eric Auger wrote:
>> Introduce support for GTree migration. A custom save/restore
>> is implemented. Each item is made of a key and a data.
>>
>> If the key is a pointer to an object, 2 VMSDs are passed into
>> the GTree VMStateField.
>>
>> Whe
* Eric Auger (eric.au...@redhat.com) wrote:
> Introduce support for GTree migration. A custom save/restore
> is implemented. Each item is made of a key and a data.
>
> If the key is a pointer to an object, 2 VMSDs are passed into
> the GTree VMStateField.
>
> When putting the items, the tree is t
On Fri, Oct 04, 2019 at 01:20:25PM +0200, Eric Auger wrote:
> Introduce support for GTree migration. A custom save/restore
> is implemented. Each item is made of a key and a data.
>
> If the key is a pointer to an object, 2 VMSDs are passed into
> the GTree VMStateField.
>
> When putting the item
Eric Auger wrote:
> Introduce support for GTree migration. A custom save/restore
> is implemented. Each item is made of a key and a data.
>
> If the key is a pointer to an object, 2 VMSDs are passed into
> the GTree VMStateField.
>
> When putting the items, the tree is traversed in sorted order by
Introduce support for GTree migration. A custom save/restore
is implemented. Each item is made of a key and a data.
If the key is a pointer to an object, 2 VMSDs are passed into
the GTree VMStateField.
When putting the items, the tree is traversed in sorted order by
g_tree_foreach.
On the get()
12 matches
Mail list logo
