Are calls to a tty driver's open()/close() methods serialized by the
tty layer? If so, has this always been the case?
I'm working on converting an old tty driver over to using the "new"
tty_port_* functions and the standard "struct tty_port" port data
structure.
[I thought about converting it to a uart driver for serial_core, but
AFAICT, that API doesn't provide any way to return errors for
userspace open() and write() calls and would therefore break my
user-land API.]
>From looking at example tty drivers in the 3.7.2 source tree, it
appears that they assume calls to open()/close() are serialized.
The old driver I'm working on had its own internal locking to protect
race conditiions when incrementing and decrementing of a port's open
count. That counter is being prelaced by tty->port->count, and in
existing in-kernel tty drivers it doesn't look like there is any
locking when that count is incremented during an open().
For example, from rocket.c:
891 static int rp_open(struct tty_struct *tty, struct file *filp)
892 {
[...]
924 tty->driver_data = info;
925 tty_port_tty_set(port, tty);
926
927 if (port->count++ == 0) {
928 atomic_inc(&rp_num_ports_open);
929
930 #ifdef ROCKET_DEBUG_OPEN
931 printk(KERN_INFO "rocket mod++ = %d...\n",
932 atomic_read(&rp_num_ports_open));
933 #endif
934 }
If calls to open()/close() aren't serialized, then line 927 would
cause a race condition...
--
Grant Edwards grant.b.edwards Yow! Everybody gets free
at BORSCHT!
gmail.com
--
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
