Re: [Qemu-devel] [PATCH v2 01/13] block: Make essential BlockDriver objects public

[Max Reitz <mreitz@redhat.com>]

On 2014-12-01 at 16:59, Eric Blake wrote:
> On 11/27/2014 07:48 AM, Max Reitz wrote:
>> There are some block drivers which are essential to QEMU and may not be
>> removed: These are raw, file and qcow2 (as the default non-raw format).
>> Make their BlockDriver objects public so they can be directly referenced
>> throughout the block layer without needing to call bdrv_find_format()
>> and having to deal with an error at runtime, while the real problem
>> occured during linking (where raw, file or qcow2 were not linked into
> s/occured/occurred/
>
>> qemu).
>>
>> Cc: qemu-stable@nongnu.org
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>> ---
>>   block/qcow2.c             | 4 ++--
>>   block/raw-posix.c         | 4 ++--
>>   block/raw-win32.c         | 4 ++--
>>   block/raw_bsd.c           | 4 ++--
>>   include/block/block_int.h | 8 ++++++++
>>   5 files changed, 16 insertions(+), 8 deletions(-)
> Reviewed-by: Eric Blake <eblake@redhat.com>
>
>> +++ b/block/qcow2.c
>> @@ -2847,7 +2847,7 @@ static QemuOptsList qcow2_create_opts = {
>>       }
>>   };
>>   
>> -static BlockDriver bdrv_qcow2 = {
>> +BlockDriver *bdrv_qcow2 = &(BlockDriver){
> Do we want any use of 'const', to avoid accidental manipulation of the
> pointer and/or pointed-to contents?

Sounds good at first, but for instance qemu_opts_create() (which is 
often called with bdrv_qcow2->create_opts and the like) don't take a 
const pointer. We could fix all those functions, but trying to fix the 
const-ness of the block layer sounds like really tedious work to me... 
Also, bdrv_find_format() returns a non-const pointer so it's at least 
not more broken than it was before.

Max