qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: A new direction for vmchannel?


From: Jamie Lokier
Subject: Re: [Qemu-devel] Re: A new direction for vmchannel?
Date: Sat, 24 Jan 2009 21:00:26 +0000
User-agent: Mutt/1.5.13 (2006-08-11)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]