Messages in this thread | | | Date | Fri, 18 Jul 1997 21:44:37 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: 2.0.30 serial.c, ppp.c and pppd-2.2 questions |
| |
Date: Fri, 18 Jul 1997 18:07:22 -0600 From: Rob Riggs <rob@DevilsThumb.COM>
In serial.c's receive_char() interrupt handler we read a char from the UART then just drop it if the flip buffer is full. If we are going to do this we should indicate an overflow error. An alternative solution is to test if the flip buffer is full before we read the UART and just break out of the read loop.
The reason why we have to read chars from the UART even if the flip buffer is full is because if we don't, the serial interrupt flag never goes to zero, and we either loop endlessly in a loop (if the interrupt is level triggered, as in some PCMCIA cards) or never take another interrupt from the UART again (if the interrupt is edge triggered, which is typical for most PC cards).
You're right that setting an overflow error is the most appropriate thing to do; however, reporting an overrun error itself requires a space in the flip buffer, which we won't have if the flip buffer is full.....
If we don't read the UART data when the flip buffer is full it would be nice to mask the "data ready" interrupt until we have an empty flip buffer. This would require a callback from the tty layer's flush_to_ldisc() to notify us that the flip buffer has been flipped. This would also allow flow control based on how full the flip buffer is.
This is one way we could solve things; however, in practice the flip buffer should really never overflow --- especially at baudrates of 230400 or below. If it does, there's something really wrong with the system....
In pppd, the code sets up the tty to IGNPAR & IGNBRK. In serial.c, if both of those are set, then it ignores parity errors and breaks, but also overflow errors. If we receive any of these errors in serial.c during a ppp connection, they are ignored.
Specifically, this casues serial.c to not include parity errors and breaks in the flip buffer at all.... It's probably the wrong thing, if ppp.c is actually testing for errors in the tty flip buffer.
1. Should pppd really be setting the tty to IGNPAR & IGNBRK?
Probably not.
2. Should serial.c ignore overflows if IGNPAR & IGNBRK are set? (I'm not sure what POSIX has to say about it. I didn't see anything mentioned in the books that I have.)
Yes. POSIX doesn't mention overflows at all. However, serial.c ignores overflows in this case because this if IGNPAR and IGNBRK are set, this casues fast-track processing in N_TTY layer which assumes that there won't be extraneous characters in the flip character buffer. (This is the real raw mode support.)
3. Should we drop data when the flip buffer is full and not report it as an overflow? (Again, POSIX may indicate what is and isn't allowed.)
4. Should we drop data at all, or should we let the UART overflow on its own and report the error to us? (We would need to mask the "data ready" interrupt until there is an empty flip buffer available.)
5. Are there any problems with doing flow control based on how full the flip buffer is?
Consider... the flip buffer should be flipped on every clock tick (100 times a second). The flip buffer is 512 bytes. So at anything under 512000 bps, the flip buffer should be able to keep up.
- Ted
| |