qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 96/97] vmstate: Rename VMS_VBUFFER to VMST_VBUFF


From: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH 96/97] vmstate: Rename VMS_VBUFFER to VMST_VBUFFER_INT32 for consintency
Date: Mon, 07 Apr 2014 11:54:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

"Dr. David Alan Gilbert" <address@hidden> wrote:
> * Juan Quintela (address@hidden) wrote:
>> Signed-off-by: Juan Quintela <address@hidden>
>> ---
>>  include/migration/vmstate.h | 6 +++---
>>  vmstate.c                   | 2 +-
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
>> index 976d83e..145c198 100644
>> --- a/include/migration/vmstate.h
>> +++ b/include/migration/vmstate.h
>> @@ -96,7 +96,7 @@ enum VMStateFlags {
>>      VMS_BUFFER           = 0x020,  /* static sized buffer */
>>      VMS_ARRAY_OF_POINTER = 0x040,
>>      VMS_VARRAY_UINT16    = 0x080,  /* Array with size in uint16_t field */
>> -    VMS_VBUFFER          = 0x100,  /* Buffer with size in int32_t field */
>> +    VMS_VBUFFER_INT32    = 0x100,  /* Buffer with size in int32_t field */
>>      VMS_VBUFFER_UINT32   = 0x200,  /* Buffer with size in uint32_t field */
>>      VMS_VARRAY_UINT8     = 0x400,  /* Array with size in uint8_t field*/
>>      VMS_VARRAY_UINT32    = 0x800,  /* Array with size in uint32_t field*/
>> @@ -436,7 +436,7 @@ extern const VMStateInfo vmstate_info_bitmap;
>>      .name         = (stringify(_field)),                             \
>>      .size_offset  = vmstate_offset_value(_state, _field_size, int32_t),\
>>      .info         = &vmstate_info_buffer,                            \
>> -    .flags        = VMS_VBUFFER|VMS_POINTER,                         \
>> +    .flags        = VMS_VBUFFER_INT32|VMS_POINTER,                   \
>
> Are there any real users of the code where it's really an INT32 value - can
> we just not kill off the silly idea of signed buffer sizes altogether?
>
> (The only case I can follow through is onenand.c that has a PARTIAL_VBUFFER
> based on an 'int' called 'blocks', that's derived during init from an unsigned
> value and passed to things like mallocs and memsets, so it's never going to be
> negative).

There is one user :-(

Note the VARRAY thing, where there are more.  And normally it depends on
the target device if it is signed or not

Later, Juan.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]