From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53316) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpcWy-0004j9-UR for qemu-devel@nongnu.org; Fri, 13 Jul 2012 05:51:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SpcWr-0000HA-3I for qemu-devel@nongnu.org; Fri, 13 Jul 2012 05:51:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22067) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SpcWq-0000H6-R1 for qemu-devel@nongnu.org; Fri, 13 Jul 2012 05:51:17 -0400 Message-ID: <4FFFEF8E.5080705@redhat.com> Date: Fri, 13 Jul 2012 11:51:10 +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> <4FFBD6F1.90403@redhat.com> <20120713091611.GC15503@stefanha-thinkpad.localdomain> In-Reply-To: <20120713091611.GC15503@stefanha-thinkpad.localdomain> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Stefan Hajnoczi Cc: Anthony Liguori , Wenchao Xia , qemu-devel@nongnu.org Il 13/07/2012 11:16, Stefan Hajnoczi ha scritto: >> "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. It doesn't really, not on Windows which has no AIO for example. That's why I suggested: - assessing what code is GPL and what are the dependencies on it - only including the formats in the library + a synchronous file protocol. No NBD, no libiscsi, no hdev, etc. My suspicion is that with this strategy the only complicated dependency is on coroutines. Paolo