Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API

[Paolo Bonzini]

Il 10/07/2012 07:04, Wenchao Xia ha scritto:
> 于 2012-7-9 17:13, Paolo Bonzini 写道:
>> Il 09/07/2012 10:54, Wenchao Xia ha scritto:
>>> Following is my implementing plan draft:
>>>    1 introduce libqblock.so in sub directory in qemu.
>>>    2 write a nbd client in libqblock, similar to qemu nbd client. Then
>>> use it to talk with nbd server, by default is qemu-nbd, to get access
>>> to images. In this way, libqblock.so could be friendly LGPL licensed.
>>
>> Did you actually assess the license situation of the block layer?
>> block.c and large parts of block/* are under a BSD license, for example.
>>   If the library only has to support raw files, it might do so using
>> synchronous I/O only.  This would remove a large body of GPL-licensed code.
>>
>   If the library was built as nbd-client communicating with nbd-server,
> which then employ the BSO licensed code, could the library ignore the
> server side's license problem?

Yes, but if your first worry is the legal problem you are doomed to
design an awful library.

> The reason using nbd-client approach are:
> work around qemu block layer license issue and easy to implement

"Working around the QEMU block layer license" is not a goal per se,
especially because you haven't a) assessed _what_ is the GPL code that
the library would use; b) told us why the library should not be under
the GPL.

Please design first according to the functionality you want to
implement, then think about the implementation.

> , if
> other tool found this labrary useful then considering about directly
> employ the qemu block code.

Again, I find this to be quite backwards.  Writing a replacement for the
QEMU block layer just for licensing reasons is going to be a waste of
resources, since 90% of it is already BSD-licensed.

Perhaps you can produce two variants of the library, one using GPLed
backends and one entirely under the BSD license.  That would be good.
However we cannot help much in finding the best way to reach your goals,
again because you haven't reported on what actually is the GPL code that
you're worried about and why.

>>>    3 still not got a good way to get additional info in (2)(3)(4),
>>> currently in my head is patch qemu-nbd to add an additional nbd command,
>>> "image-info", in which returns related info.
>>
>> On the Linux kernel mailing list I would have no qualms labeling such
>> command as "crap".  However, since the social standards on qemu-devel
>> are a bit higher, I'll ask instead: what information would the command
>> provide beyond the size?
>>
>   The API need to report the image format it is using, such as
> "qcow2". And also API should report if a block at offset have been
> allocated or it is a hole.

qemu-nbd is designed to always provide the image format as raw, so its
client has no business knowing whether the image is originally stored as
qcow2 or something else.

Paolo