[Top][All Lists]

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

Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communic

From: Gerd Hoffmann
Subject: Re: [Qemu-devel] Re: virtio-serial: An interface for host-guest communication
Date: Mon, 10 Aug 2009 11:47:54 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2

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

... and within the guest

  /dev/vmchannel/org/qemu/clipboard  and

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.


reply via email to

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