From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37273) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOyJw-000511-03 for qemu-devel@nongnu.org; Tue, 02 Sep 2014 20:21:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOyJp-0004nA-SL for qemu-devel@nongnu.org; Tue, 02 Sep 2014 20:21:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17450) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOyJp-0004my-KO for qemu-devel@nongnu.org; Tue, 02 Sep 2014 20:21:01 -0400 Message-ID: <54065EE7.4080601@redhat.com> Date: Tue, 02 Sep 2014 17:20:55 -0700 From: Andy Grover MIME-Version: 1.0 References: <20140829172218.GD16755@irqsave.net> <20140902092510.GC29067@stefanha-thinkpad.redhat.com> In-Reply-To: <20140902092510.GC29067@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] tcmu-runner and QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , =?ISO-8859-1?Q?Beno=EEt_Cane?= =?ISO-8859-1?Q?t?= Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org On 09/02/2014 02:25 AM, Stefan Hajnoczi wrote: > The easiest approach is to write a tool similar to qemu-nbd that speaks > the userspace target protocol (i.e. mmap the shared memory). > If the tcmu setup code is involved, maybe providing a libtcmu with the > setup code would be useful. I suspect that other projects may want to > integrate userspace target support too. It's easier to let people add > it to their codebase rather than hope they bring their codebase into > tcmu-runner. What other projects were you thinking of? From my perspective, QEMU is singular. QEMU's block support seems to cover just about everything, even ceph, gluster, and sheepdog! We certainly don't want to duplicate that code so a qemu-lio-tcmu in qemu.git like qemu-nbd, basically statically linking the BlockDriver object files, sounds like the first thing to try. We can make tcmu-runner a library (libtcmu) if it makes sense, but let's do some work to try the current way and see how it goes before "flipping" it. > The qemu-lio tool would live in the QEMU codebase and reuse all the > infrastructure. For example, it could include a QMP monitor just like > the one you are adding to qemu-nbd. Benoit and I talked a little about QMP on another part of the thread... I said I didn't think we needed a QMP monitor in qemu-lio-tcmu, but let me spin up on qemu a little more and I'll be able to speak more intelligently. -- Andy