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: Gerd Hoffmann on 15 Sep 2009 10:10 On 09/15/09 14:57, Anthony Liguori wrote: > That's probably not what we want. I imagine what we want is: > > /dev/ttyV0 > /dev/ttyV1 > /dev/ttyVN Yes. > And then we want: > > /sys/class/virtio-console/ttyV0/name -> "org.qemu.clipboard" Yes. > 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. cheers, Gerd -- 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 16 Sep 2009 18:30 Alan Cox wrote: >> This device is very much a serial port. I don't see any reason not >> to treat it like one. >> > > Here are a few > > - You don't need POSIX multi-open semantics, hangup and the like > We do actually want hangup and a few other of the tty specific ops. The only thing we really don't want is a baud rate. > - Seek makes sense on some kinds of fixed attributes > I don't think we're dealing with fixed attributes. These are streams. Fundamentally, this is a paravirtual uart. The improvement over a standard uart is that there can be a larger number of ports, ports can have some identification associated with them, and we are not constrained to the emulated hardware interface which doesn't exist on certain platforms (like s390). > - TTY has a relatively large memory overhead per device > - Sysfs is what everything else uses > - Sysfs has some rather complete lifetime management you'll need to > redo by hand > sysfs doesn't model streaming data which is what this driver provides. > - You don't need idiotic games with numbering spaces > > Abusing tty for this is ridiculous. If the argument is that tty is an awkward interface that should only be used for legacy purposes, then sure, we should just implement a new userspace interface for this. In fact, this is probably supported by the very existence of hvc. On the other hand, this is fundamentally a paravirtual serial device. Since serial devices are exposed via the tty subsystem, it seems like a logical choice. > In some ways putting much of it in > kernel is ridiculous too as you can do it with a FUSE fs or simply > export the info guest-guest using SNMP. > This device cannot be implemented as-is in userspace because it depends on DMA which precludes the use of something like uio_pci. We could modify the device to avoid dma if the feeling was that there was no interest in putting this in the kernel. 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 18 Sep 2009 17:10 H. Peter Anvin wrote: > On 09/18/2009 10:55 AM, Anthony Liguori wrote: > >> I fail to see how this is at all relevant. This is a virtual machine, >> we're presenting virtual hardware that behaves like a serial device. >> Where web servers fit in is completely beyond me. >> >> > > s/virtio_console/virtio_serial/ > > There is a fairly noticeable difference between a "console device" and a > "serial device". However, something that can be extended and exported > to a physical serial port is definitely the latter. > Indeed. I think part of the confusion here is that virtio_console started as just as console and hence it used hvc. As part of the current reworking, I think it makes sense to rename the driver virtio_serial. Regards, Anthony Liguori > -hpa > > -- 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: H. Peter Anvin on 18 Sep 2009 17:10 On 09/18/2009 10:55 AM, Anthony Liguori wrote: > > I fail to see how this is at all relevant. This is a virtual machine, > we're presenting virtual hardware that behaves like a serial device. > Where web servers fit in is completely beyond me. > s/virtio_console/virtio_serial/ There is a fairly noticeable difference between a "console device" and a "serial device". However, something that can be extended and exported to a physical serial port is definitely the latter. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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: Gerd Hoffmann on 18 Sep 2009 17:10
On 09/18/09 19:55, Anthony Liguori wrote: >> So you need break, parity ... no be serious please > > Sure, why not? > > In QEMU, we have the ability to hook our devices directly to a physical > serial device and we pass through break, parity, and the other serial > device properties. Yes for a emulated 16550. No for virtio-console. If you want the guest drive some silly piece of hardware which wants a serial mode != 8N1 or needs breaks you can't use virtio-console. > Again, this is paravirtual serial device and I think it's entirely > reasonable for people to hook up these ports in the guest directly to > physical serial devices in the host. Except that the paravirtual device named 'virtio-console' simply doesn't allow to set serial parameters such as parity, data bits and stop bits. It is *really* just a (single) byte stream piped over a virtio ring. The guest side happens to be connected to hvc, so you can use that as console, thus the name 'virtio-console'. The plan is to extend that to multiple byte streams. The streams can be hooked up to hvc (and one stream allways will be for backward compatibility reasons), giving you a text console. Or they can be linked to a character device with a name tag (aka sysfs attribute), providing a named bidirectional byte stream for guest<->host communication. > From my perspective, this is a paravirtual serial device and nothing > more. It simply isn't, see above. > All the discussion of things like guest copy/paste support is a > bit silly. Implementing transparent copy/paste support needs some communication channel between guest and host. The multiport virtio console driver provides just that. > This is the wrong way to approach that sort of thing because > it's not something that belongs in the kernel at all. Who claimed the copy/paste bits should go into the kernel? They will not of course. > Furthermore, the > current proposal doesn't handle anything like save/restore which is > needed for live migration. That is something the host side (i.e. qemu) has to solve. The guest will not care about it at all ;) cheers, Gerd -- 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/ |