29.09.2013 07:21, Grant Edwards пишет:
I was thinking about initially just creating a blocking ioctl() call
that the master can use to wait for either a termios configuration
change or a modem control line change. I admit that's not as elegent:
it would mean a master would need multiple threads in most cases (one
for data and one for config and modem status). But, it may be a less
intrusive change [I haven't looked at the poll implementation in any
detail, so perhaps the poll change isn't as bad as I fear.]
The simplier way is to use master in 'packet mode' (see TIOCPKT). Then
we can distinguish stream data from termios notification for every
master's read. It either starts with '\0' and the following is the data
to transmit or with control symbol and then master have to use ioctl to
read new tty->termios.
Having to use multiple threads in a master sounds ugly at first, but
it's still orders of magnitude easier than implementing a serial
driver in kernel space that uses network I/O to communicate with the
physical UART.
For sure.
We need way more ioctls. Since every new slave pty is enumerated almost
randomly (depends on how many sessions is opened, opening order, etc),
we have to mark somehow the pty when the daemon creates it, then udev
should be able to create appropriate symbolic link for client user-space
application. Then user-space client may be configured to work with
/dev/tty/by-name/uniqname for instance.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
