On (Tue) Sep 15 2009 [07:57:10], Anthony Liguori wrote:
Amit Shah wrote:
Hey Greg,That's probably not what we want. I imagine what we want is:
Can you tell me how this could work out -- each console port could have
a "role" string associated with it (obtainable from the invoking qemu
process in case of qemu/kvm). Something that I have in mind currently
is:
$ qemu-kvm ... -virtioconsole role=org/qemu/clipboard
and then the guest kernel sees the string, and puts the
"org/qemu/clipboard" in some file in sysfs. Guest userspace should then
be able to open and read/write to
/dev/virtio_console/org/qemu/clipboard
/dev/ttyV0
/dev/ttyV1
/dev/ttyVN
And then we want:
/sys/class/virtio-console/ttyV0/name -> "org.qemu.clipboard"
Userspace can detect when new virtio-consoles appear via udev events. When it sees a new ttyVN, it can then look in sysfs to discover it's name.
OK; but that's kind of roundabout isn't it? An application, instead of
watching for the console port it's interested in, has to instead monitor
all the ports.
So in effect there has to be one app monitoring for new ports and then
that app exec'ing the corresponding app meant for that port.