Re: [Qemu-devel] [RFC][PATCH v3 00/21] virtproxy: host/guest communication layer

[Michael Roth <mdroth@linux.vnet.ibm.com>]

On 11/16/2010 04:28 PM, Michael Roth wrote:
> 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
>

Argh, -device virtserialport

>>> # 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.
>

"isa-serial"/"virtio-serial"