[Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Gerd Hoffmann
kraxel at redhat.com
Mon Aug 10 02:47:54 PDT 2009
On 08/10/09 08:55, Amit Shah wrote:
>> Bad example. Quite a lot of modern devices drivers are using dynamic
>> major/minor numbers because they have proven to be such a pain in the
>> butt. That's why we have more sophisticated mechanisms like udev for
>> userspace to make use of.
>
> Let me explain how we came to this numbering: we first had support for
> 'naming' ports and the names were obtained by userspace programs by an
> ioctl. Rusty suggested to use some numbering scheme where some ports
> could exist at predefined locations so that we wouldn't need the naming
> and the ioctls around it.
I think the naming is very important. The guest needs to know who is
listening on the other end of the line. I think a sysfs attribute (as
suggested by Jamie IIRC) will work nicely here. So each device gets a
property called 'class' or 'protocol' or something simliar named,
therein a string which specifies the protocol it speaks.
Host side would look like this:
-virtioserial port=4,protocol=clipboard
... in case the protocol is implemented in qemu or like this:
-virtioserial port=2,protocol=libguestfs,char=unix:something
... for stuff provided by external apps.
Within the guest the two lines above would create vmch4 and vmch2, both
having a protocol attribute, and udev then can create symlinks named by
protocol, i.e.
/dev/vmchannel/clipboard symlinked to /dev/vmch4 and
/dev/vmchannel/libguestfs symlinked to /dev/vmch2
The port=<nr> attribute can be optional and dynamically auto-allocated
by default.
>> So for instance, I could have an "com.ibm.my-awesome-channel" and never
>> have to worry about conflicts.
reverse fqdn name space is a good idea. We don't need a central
protocol name registry then. The examples above would then become
something like this:
protocol=orq.qemu.clipboard and
protocol=org.libguestfs.fish
... and within the guest
/dev/vmchannel/org/qemu/clipboard and
/dev/vmchannel/org/libguestfs/fish
> There are some other problems with usb too: It's not transparent to
> users. Any hotplug event could alert users and that's not desired. It's
> a system-only thing and should also remain that way.
I think virtio-serial is the better way to handle vmchannel. Unlike usb
virtio is designed to work nicely in a virtual environment.
But vmchannel-over-usbserial should be easy too though in case some
guests lacks virtio backports or something. I think you can just stick
a name like "vmchannel:orq.qemu.clipboard" into the usbserial product
name, then have udev match that and create
/dev/vmchannel/org/qemu/clipboard symlinking to /dev/ttyUSB<nr>
Voila, you can switch transports and the apps don't even notice.
cheers,
Gerd
More information about the Virtualization
mailing list