Wow, good catches. I'd simplified the examples with v2 and failed to
correct some of the typos I introduced then when sending out v3. Your
intuition is correct on most of these:
On 11/16/2010 03:57 PM, Stefan Hajnoczi wrote:
Is virtconsole just a way of throwing something on the virtio-serial
bus? A quick peek at hw/virtio-console.c suggests "virtserialport"
could also be used (and would be more intuitive because we don't want
a console, just a serial port)?
Yup, that's supposed to be -device virtserial
# in the guest:
./qemu-vp -c virtserial-open:/dev/virtio-ports/test2:- -i
http:127.0.0.1:80 \
-i ssh:127.0.0.1:22
name=test0 above. Is this a typo or where does test2 come from?
Yup, should be /dev/virtio-ports/test0
What does "virtserial-open" mean? Why not
virtio-serial:/dev/virtio-ports/test2 to match the "-device
virtio-serial" above? Virtio has a naming issue, every implementation
names things slightly differently :).
I added a verb because I was trying to stick with the convention for the
unix-(connect|listen)/tcp-(connect|listen) methods used in earlier
versions of qemu-vp (when it was run in the host as well as the guest,
and connected to/listen for data from a channel via a -chardev
socket,... or direct tcp connection). Now that the host daemon has been
replaced with a virtproxy chardev these actually don't have much use
anymore, and the tcp support has been dropped entirely...
So just plain "isa-serial"/"virtserial" might be a bit more intuitive
now, since now there's a clear mapping between the channel type we
specify to qemu-vp and the -device used for the channel. I'll go ahead a
make this change.