> Just one question: I looked at n_tty_receive_buf and I didn't see any
> protection / warn back mechanism (the function is void) as to "what if the
> room in the TTY buffer is too small to store all the data passed
> directly by the driver". What happens if the driver passes a data amount
> that's bigger than the available room in the TTY buffer??
>
> The line discpline is responsible to calling the driver's
> throttle()/unthrottle() as the space in the tty buffer goes above and
> below the high and low watermarks; this is how hardware (and software)
> flow control is handled.
>
> Linux gives plenty of time (something like 768 characters, if I remember
> correctly) for the sending device to stop sending characters; if the
> sending device ignores the flow control, the tty layer does the only
> thing it can do --- it drops the data on the floor.
This I know, but I guess you didn't understand my question.
>From what I understood, what the Rocketport driver does is:
- Copy data from the hardware to a memory buffer (coincidentally, but not
necessarily, the flip buffer, correct ?!?!);
- Call ldisc.receive_buf directly, passing the memory buffer address and
the number of bytes on this buffer (among other arguments);
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??
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??
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 ...
Regards,
Ivan
-
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/