Amit Shah wrote: > On (Tue) Sep 15 2009 [07:57:10], Anthony Liguori wrote: > >> Amit Shah wrote: >> >>> Hey Greg, >>> >>> 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 >>> >>> >> That's probably not what we want. I imagine what we want is: >> >> /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. > If you wanted to use /dev/virtio/org/qemu/clipboard you still have the same problem. You have to use udev or inotify to listen for a new file in a directory. The /dev/ path may look nicer from a high level, but the code ends up being roughly the same for either approach. What I propose has the advantage of looking like existing subsystems. It also avoids encoding device information in the device name. > 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. > I think if you think through both models, they end up looking the same. Regards, Anthony Liguroi _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
