My question is: what happens if the number of bytes passed to
ldisc.receive_buf is bigger than the number of available bytes in the TTY
buffer??
I guess you didn't understand my answer. :-)
If the number of bytes passed to ldisc.receive_buf is bigger than the
number of available bytes in the tty buffer, the execess characters are
dropped by the line discpline. They're dropped on the floor.
My concern is because with the flip buffers, the data was in a "safe
place", i.e., in a place the TTY driver knows the location, so that it
could go back to it later if necessary. With the flip buffer bypass, the
location of the buffer is random (i.e., depends on the serial driver), so
how will the TTY driver handle the data that it couldn't place in its
internal TTY buffer due to lack of space??
The data is dropped on the floor. That's all you can do. Even if
you're using the flip buffer, the data isn't in a safe place, because
the flip buffer has to get reused when more characters come in via the
interrupt handler. It doesn't make sense to add complexity by using the
flip buffer as additional buffering space; ultimately, if the other side
ignores the flow control signals, and the 4k tty buffer is full, you're
going to have to drop characters on the floor. So if the tty buffer is
full, the data is dropped.
One more question: if the driver is supposed to know this limit
beforehand, where can it get this information (i.e., info about how many
bytes are available in the TTY Rx buffer) ?? I don't see any check of this
kind in the Rocketport driver ...
The driver doesn't need to know this limit beforehand, because there's
nothing it can do with the data. It's the responsibility of the
high-level tty driver code to monitor the space in the tty buffer, and
as I've explained earlier, it sends the driver a flow control signal
when the buffer starts getting full, and gives the other device 768
character times to stop sending characters. If the other side ignores
flow control, all you can do is drop data on the floor.
So the driver, doesn't need to know this in advance. The line discpline
simply processes as much data as it can, and it drops the rest. It
can't do anything else, and it doesn't make sense for it to try anything
else.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/