Alan Cox wrote: >> 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. >> > > 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. 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. >> 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. >> > > So you need a tiny kernel side driver to unpack it into a meaningful > fs, or just a user-user channel with a daemon each end and a protocol > over it - nothing kernel in that. > I think there's some confusion over what this driver actually is. From my perspective, this is a paravirtual serial device and nothing more. All the discussion of things like guest copy/paste support is a bit silly. This is the wrong way to approach that sort of thing because it's not something that belongs in the kernel at all. Furthermore, the current proposal doesn't handle anything like save/restore which is needed for live migration. > We don't implement tcp/ip http sessions as tty devices with the kernel > as web server and the same logic applies here. > 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. Regards, Anthony Liguori _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
