virtio_console: Add support for multiple ports for generic guest and host communication
in [Kernel]
|
Prev: virtio_console: Add support for multiple ports for generic guest and host communication
Next: Hello
From: Anthony Liguori on 11 Sep 2009 13:30 Amit Shah wrote: > Right; there was some discussion about this. A few alternatives were > suggested like > > - udev scripts to create symlinks from ports to function, like: > > /dev/vcon3 -> /dev/virtio-console/clipboard > > - Some fqdn-like hierarchy, like > > /dev/virtio-console/com/redhat/clipboard > > which again can be created by udev scripts > And I dislike all of them. What I'd rather have is these devices exposed as tty's with a sys attribute that exposed the name of the device. This is not all that different to how usb serial devices work. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Anthony Liguori on 11 Sep 2009 13:40 Amit Shah wrote: > On (Fri) Sep 11 2009 [12:26:16], Anthony Liguori wrote: > >> Amit Shah wrote: >> >>> Right; there was some discussion about this. A few alternatives were >>> suggested like >>> >>> - udev scripts to create symlinks from ports to function, like: >>> >>> /dev/vcon3 -> /dev/virtio-console/clipboard >>> >>> - Some fqdn-like hierarchy, like >>> >>> /dev/virtio-console/com/redhat/clipboard >>> >>> which again can be created by udev scripts >>> >>> >> And I dislike all of them. What I'd rather have is these devices >> exposed as tty's with a sys attribute that exposed the name of the >> device. >> > > A sysfs attribute can even be exposed with a char device. > > I didn't want to venture more into tty after the hvc thing and the > unexpected bugs that crept up (memory corruption, which is now fixed in > linux-next). I'd rather just keep it limited to the subsystems I know. > I don't think that's a good justification. This device is very much a serial port. I don't see any reason not to treat it like one. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Anthony Liguori on 15 Sep 2009 09:00 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. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Anthony Liguori on 15 Sep 2009 09:40 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Anthony Liguori on 15 Sep 2009 10:10
Gerd Hoffmann wrote: >> 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. > > No. udev can create symlinks for you, so apps don't have to dig into > sysfs. You'll need a rule along the lines (untested): > > SUBSYSTEM=="virtio", \ > DRIVERS="virtio-console", \ > SYMLINK+="vcon/$attr{name}" > > then udev will create a /dev/vcon/org.qemu.clipboard symlink pointing > to dev/ttyV0. Apps can just open /dev/vcon/$name then. That works equally well. I don't necessarily think that naming is more useful. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |