From: Jamie Lokier <jamie@shareable.org>
To: qemu-devel@nongnu.org
Cc: Gleb Natapov <gleb@redhat.com>,
Eric Van Hensbergen <ericvanhensbergen@us.ibm.com>,
Chris Wright <chrisw@redhat.com>, kvm-devel <kvm@vger.kernel.org>,
Dor Laor <dlaor@redhat.com>, Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] Re: A new direction for vmchannel?
Date: Sat, 24 Jan 2009 21:00:26 +0000 [thread overview]
Message-ID: <20090124210026.GA22932@shareable.org> (raw)
In-Reply-To: <497B6C4F.1040803@codemonkey.ws>
Anthony Liguori wrote:
> Thinking more about this, the difficulty is that poll() only has useful
> semantics when you're dealing with a buffered stream of some sort. That
> is, poll() is only really capable of asking whether there is data
> pending in your read buffer.
>
> With 9P, you have to explicitly send a read request. You can implement
> buffered IO by simply sending constant read requests such that there is
> always one read request pending. I don't think it's useful to do this
> in the kernel.
In linux/Documentation/fs/9p.txt:
nodevmap do not map special files - represent them as normal files.
This can be used to share devices/named pipes/sockets between
hosts. This functionality will be expanded in later versions.
Does this mean it can provide the semantics of a named pipe
or unix domain socket over 9p?
Both would provide suitable poll() behaviour. A unix domain socket
sounds especially useful, practically a drop in replacement for the
current network vmchannel, without configuration downsides.
But what about non-Linux guests?
> Unfortunately, there's no way to do async IO in userspace that doesn't
> suck so that would make this pretty difficult. We could use a thread
> pool, but that's somewhat soul crushing and doesn't scale well. I think
> that puts a requirement on v9fs to support linux-aio.
It sounds like a weird mashup of unix regular file behaviour and unix
socket behaviour. Poll doesn't work, aio might, but you can
read/write like a stream? Very un-unix.
Even if it can be made to work, that's sufficiently un-unix to reduce
its general utility with existing scripting languages, existing
monitoring programs etc.
-- Jamie
WARNING: multiple messages have this Message-ID (diff)
From: Jamie Lokier <jamie@shareable.org>
To: qemu-devel@nongnu.org
Cc: Eric Van Hensbergen <ericvanhensbergen@us.ibm.com>,
Chris Wright <chrisw@redhat.com>, Gleb Natapov <gleb@redhat.com>,
kvm-devel <kvm@vger.kernel.org>, Dor Laor <dlaor@redhat.com>,
Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] Re: A new direction for vmchannel?
Date: Sat, 24 Jan 2009 21:00:26 +0000 [thread overview]
Message-ID: <20090124210026.GA22932@shareable.org> (raw)
In-Reply-To: <497B6C4F.1040803@codemonkey.ws>
Anthony Liguori wrote:
> Thinking more about this, the difficulty is that poll() only has useful
> semantics when you're dealing with a buffered stream of some sort. That
> is, poll() is only really capable of asking whether there is data
> pending in your read buffer.
>
> With 9P, you have to explicitly send a read request. You can implement
> buffered IO by simply sending constant read requests such that there is
> always one read request pending. I don't think it's useful to do this
> in the kernel.
In linux/Documentation/fs/9p.txt:
nodevmap do not map special files - represent them as normal files.
This can be used to share devices/named pipes/sockets between
hosts. This functionality will be expanded in later versions.
Does this mean it can provide the semantics of a named pipe
or unix domain socket over 9p?
Both would provide suitable poll() behaviour. A unix domain socket
sounds especially useful, practically a drop in replacement for the
current network vmchannel, without configuration downsides.
But what about non-Linux guests?
> Unfortunately, there's no way to do async IO in userspace that doesn't
> suck so that would make this pretty difficult. We could use a thread
> pool, but that's somewhat soul crushing and doesn't scale well. I think
> that puts a requirement on v9fs to support linux-aio.
It sounds like a weird mashup of unix regular file behaviour and unix
socket behaviour. Poll doesn't work, aio might, but you can
read/write like a stream? Very un-unix.
Even if it can be made to work, that's sufficiently un-unix to reduce
its general utility with existing scripting languages, existing
monitoring programs etc.
-- Jamie
next prev parent reply other threads:[~2009-01-24 21:00 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-23 14:45 A new direction for vmchannel? Anthony Liguori
2009-01-23 14:45 ` [Qemu-devel] " Anthony Liguori
2009-01-23 17:12 ` Chris Wright
2009-01-23 17:12 ` [Qemu-devel] " Chris Wright
2009-01-23 17:37 ` Anthony Liguori
2009-01-23 17:37 ` [Qemu-devel] " Anthony Liguori
2009-01-23 20:43 ` Gleb Natapov
2009-01-23 20:43 ` [Qemu-devel] " Gleb Natapov
2009-01-23 20:58 ` Anthony Liguori
2009-01-23 20:58 ` [Qemu-devel] " Anthony Liguori
2009-01-24 0:02 ` Dor Laor
2009-01-24 0:02 ` Dor Laor
2009-01-24 10:22 ` Alexander Graf
2009-01-24 10:22 ` Alexander Graf
2009-01-24 22:28 ` Dor Laor
2009-01-24 22:28 ` Dor Laor
2009-01-24 17:19 ` Daniel P. Berrange
2009-01-24 17:19 ` [Qemu-devel] " Daniel P. Berrange
2009-01-24 17:52 ` Anthony Liguori
2009-01-24 17:52 ` [Qemu-devel] " Anthony Liguori
2009-01-24 18:39 ` Gleb Natapov
2009-01-24 18:39 ` [Qemu-devel] " Gleb Natapov
2009-01-24 18:47 ` Anthony Liguori
2009-01-24 18:47 ` [Qemu-devel] " Anthony Liguori
2009-01-24 19:30 ` Anthony Liguori
2009-01-24 19:30 ` [Qemu-devel] " Anthony Liguori
2009-01-24 21:00 ` Jamie Lokier [this message]
2009-01-24 21:00 ` Jamie Lokier
2009-01-24 21:22 ` Anthony Liguori
2009-01-24 21:22 ` Anthony Liguori
2009-01-25 14:16 ` Daniel P. Berrange
2009-01-25 14:16 ` [Qemu-devel] " Daniel P. Berrange
2009-01-25 17:58 ` Anthony Liguori
2009-01-25 17:58 ` [Qemu-devel] " Anthony Liguori
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=20090124210026.GA22932@shareable.org \
--to=jamie@shareable.org \
--cc=avi@redhat.com \
--cc=chrisw@redhat.com \
--cc=dlaor@redhat.com \
--cc=ericvanhensbergen@us.ibm.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
/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.