Messages in this thread | | | Date | Wed, 16 Sep 2009 17:20:16 -0500 | From | Anthony Liguori <> | Subject | Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication |
| |
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
| |