From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoUhB-00025I-Cg for qemu-devel@nongnu.org; Tue, 10 Jul 2012 03:17:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SoUh6-0007kR-Fn for qemu-devel@nongnu.org; Tue, 10 Jul 2012 03:17:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54287) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoUh6-0007kD-73 for qemu-devel@nongnu.org; Tue, 10 Jul 2012 03:17:12 -0400 Message-ID: <4FFBD6F1.90403@redhat.com> Date: Tue, 10 Jul 2012 09:17:05 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <4FFA9C30.2070201@linux.vnet.ibm.com> <4FFAA0C3.3080703@redhat.com> <4FFBB7FB.3070303@linux.vnet.ibm.com> In-Reply-To: <4FFBB7FB.3070303@linux.vnet.ibm.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wenchao Xia Cc: Anthony Liguori , Stefan Hajnoczi , qemu-devel@nongnu.org Il 10/07/2012 07:04, Wenchao Xia ha scritto: > =D3=DA 2012-7-9 17:13, Paolo Bonzini =D0=B4=B5=C0: >> 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. The= n >>> 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 exampl= e. >> 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 comma= nd, >>> "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