qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/4] Split qcow2 driver


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 0/4] Split qcow2 driver
Date: Thu, 28 May 2009 16:56:44 +0200
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

Anthony Liguori schrieb:
> Kevin Wolf wrote:
>> The current qcow2 code is a monster of 3000 lines of code. This is hardly
>> manageable and doesn't exactly improve the driver's structure.
>>
>> This patch series tries to split the driver in smaller modules. It doesn't
>> contain changes to functionality or structure, especially the latter might 
>> come
>> later as this series makes it much clearer what the internal interfaces used 
>> by
>> the qcow2 driver actually are.
>>
>> The first three patches mainly move code around. They also build up a qcow2.h
>> header file which contains the common structs and functions used by several
>> modules. Some functions need to become global to keep things compilable.
>>
>> The fourth patch cleans up the global namespace by adding a qcow2_ prefix to
>> all of the new global functions introduced by the first patches.
>>
>> Kevin Wolf (4):
>>   qcow2: Split out refcount handling
>>   qcow2: Split out guest cluster functions
>>   qcow2: Split out snapshot functions
>>   qcow2: Rename global functions
>>   
> 
> Could you introduce a new qcow2 directory?  

I certainly could, but don't you think this is a bit too much? I mean,
block/ isn't really crowded and if we end up having a separate directory
for each file I wouldn't call this a good directory structure either.

Maybe we should wait for a few other opinions and then decide if a new
directory is the way to go or not.

> Perhaps add a README too
> that we can use to start trying to store some information about how the
> qcow2 driver works to help other people dive into it.

That would obviously be a different patch, but in general documentation
certainly wouldn't hurt. The very first thing to document would be the
image format itself, before even starting with the driver.

Kevin




reply via email to

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