From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication Date: Tue, 15 Sep 2009 08:37:39 -0500 Message-ID: <4AAF98A3.7080404__23985.9668574811$1253022061$gmane$org@codemonkey.ws> References: <1252678386-17404-1-git-send-email-amit.shah@redhat.com> <1252678386-17404-2-git-send-email-amit.shah@redhat.com> <20090911170010.34c80f2d@linux.intel.com> <20090915123752.GB5247@amit-x200.redhat.com> <4AAF8F26.8030503@codemonkey.ws> <20090915130357.GC5247@amit-x200.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20090915130357.GC5247@amit-x200.redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Amit Shah Cc: greg@kroah.com, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Alan Cox List-Id: virtualization@lists.linuxfoundation.org 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