How important is it that tty_write_room doesn't lie?

[Timur Tabi]

Greg,

As you may remember, I have a combination console/tty driver that talks to a
serial-like FIFO provided by our hypervisor.  Both tty_operations.write() and
console.write() talk to the same FIFO for character output.

I've implemented a tty_operations.write_room() function that queries the
hypervisor for amount of free space in the FIFO.  I've noticed a subtle bug in
this function, and I was hoping for some advice on how to fix it.

I believe I might have a problem when the following events happen in this order:

1) The TTY layer calls write_room() to determine the amount of free space in the
FIFO.

2) The *console* layer calls console.write() to write some data (e.g. the kernel
interrupted the TTY layer and executed a printk)

3) Control returns to the TTY layer, which calls tty_operations.write(),
assuming that the number returned by the previous call to write_room() is still
correct.

Because of the interjected console write, the FIFO no longer has a much room as
write_room() said it does.  When the TTY layer calls tty_operations.write(), my
driver returns a number smaller than the size of the buffer passed to (i.e. not
all characters were written).  The TTY layer, not expecting this, loses data.

Is my assessment of the situation correct?  If so, is there any way around this
problem that doesn't require implementing *two* software FIFOs in the driver:
one for the console interface, and one for the TTY interface?  If every driver
needs a FIFO like this, wouldn't it be simpler for the TTY and console layers to
provide their own FIFOs?  I feel like I'm missing something obvious.

-- 
Timur Tabi
Linux kernel developer at Freescale

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/