[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: A new direction for vmchannel?
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] Re: A new direction for vmchannel? |
Date: |
Sat, 24 Jan 2009 15:22:07 -0600 |
User-agent: |
Thunderbird 2.0.0.19 (X11/20090105) |
Jamie Lokier wrote:
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?
Eric will have to correct me if I'm wrong, but I believe that that bit
of functionality is not yet implemented (although it's been discussed).
But what about non-Linux guests?
The plan for non-Linux guests is to expose the 9P protocol stream down
to userspace and provide a library with posix-like file system
semantics. For instance kvmfs_open(), kvmfs_read(), kvmfs_write(),
etc. Applications that care about portability can use this library on
Linux and non-Linux.
For non-Linux guests where we can get a kernel driver in, the driver
will feed the 9P stream directly to userspace. For guests that we
cannot get a kernel driver in, we can stream 9P to the guest via TCP,
serial port, etc. This requires some config in the guest's userspace
and may require some admin intervention but that's the price you pay for
avoiding a kernel module.
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.
Right. We can certainly modify v9fs to make poll() behave more naturally.
Regards,
Anthony Liguori
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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to address@hidden
More majordomo info at http://vger.kernel.org/majordomo-info.html
- [Qemu-devel] Re: A new direction for vmchannel?, (continued)
[Qemu-devel] Re: A new direction for vmchannel?, Daniel P. Berrange, 2009/01/24
[Qemu-devel] Re: A new direction for vmchannel?, Daniel P. Berrange, 2009/01/25
[Qemu-devel] Re: A new direction for vmchannel?, Anthony Liguori, 2009/01/25