qemu-devel
[Top][All Lists]
Advanced

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

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


From: Wenchao Xia
Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API
Date: Tue, 10 Jul 2012 13:04:59 +0800
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1

于 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? The reason using nbd-client approach are:
work around qemu block layer license issue and easy to implement, if
other tool found this labrary useful then considering about directly
employ the qemu block code.


>>    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.

> Paolo
> 


-- 
Best Regards

Wenchao Xia




reply via email to

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