From: Andy Grover <agrover@redhat.com>
To: "Stefan Hajnoczi" <stefanha@redhat.com>,
"Benoît Canet" <benoit.canet@irqsave.net>
Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] tcmu-runner and QEMU
Date: Tue, 02 Sep 2014 17:20:55 -0700 [thread overview]
Message-ID: <54065EE7.4080601@redhat.com> (raw)
In-Reply-To: <20140902092510.GC29067@stefanha-thinkpad.redhat.com>
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
next prev parent reply other threads:[~2014-09-03 0:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-29 17:22 [Qemu-devel] tcmu-runner and QEMU Benoît Canet
2014-08-29 18:38 ` Andy Grover
2014-08-29 18:51 ` Benoît Canet
2014-08-29 22:36 ` Andy Grover
2014-08-29 22:46 ` Benoît Canet
2014-08-30 14:46 ` Richard W.M. Jones
2014-08-30 15:53 ` Benoît Canet
2014-08-30 16:02 ` Richard W.M. Jones
2014-08-30 16:04 ` Richard W.M. Jones
2014-08-30 17:22 ` Benoît Canet
2014-08-30 21:50 ` Benoît Canet
2014-08-30 16:51 ` Benoît Canet
2014-08-31 20:03 ` Andy Grover
2014-08-31 20:38 ` Benoît Canet
2014-09-01 8:32 ` Paolo Bonzini
2014-09-01 8:08 ` Paolo Bonzini
2014-09-02 9:25 ` Stefan Hajnoczi
2014-09-03 0:20 ` Andy Grover [this message]
2014-09-03 7:34 ` Paolo Bonzini
2014-09-03 13:11 ` Stefan Hajnoczi
2014-09-04 13:24 ` Benoît Canet
2014-09-04 15:15 ` Andy Grover
2014-09-04 15:59 ` Benoît Canet
2014-09-04 20:16 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54065EE7.4080601@redhat.com \
--to=agrover@redhat.com \
--cc=benoit.canet@irqsave.net \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.