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

[Stefan Hajnoczi]

On Tue, Jul 10, 2012 at 09:17:05AM +0200, Paolo Bonzini wrote:
> 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.

Licensing is one headache but the real challenge is that the QEMU block
layer relies on the QEMU main loop and a bunch of other architecture.

Using NBD allows us to focus on the library API instead worrying about
untangling the block layer.  If the library becomes useful it may be
worth fully moving the block layer code over into the library.

I think it makes sense to hammer out the library first before going down
a long road of internal QEMU refactoring before we know whether the
library will take off.

Stefan