Re: 2.0.30 serial.c, ppp.c and pppd-2.2 questions

Rob Riggs (rob@DevilsThumb.COM)
Sat, 19 Jul 1997 19:47:30 -0600 (MDT)


This message was intended to go out cc: to linux-kernel and
linux-net lists. Ted was kind enough to send it back to me
so I could rectify the situation.

------- Forwarded Message

From: Rob Riggs <rob@DevilsThumb.COM>
Subject: Re: 2.0.30 serial.c, ppp.c and pppd-2.2 questions
To: tytso@MIT.EDU (Theodore Y. Ts'o)
Date: Sat, 19 Jul 1997 13:02:49 -0600 (MDT)

> 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.....

It would be easy to make sure that we have at least one
byte available in the flip buffer to report overruns.

>
> 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....

How so?

> 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.)

Makes sense.

> 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.

This assumes that ldisc.receive_buf() is fast enough to
complete its task before the next clock tick. ppp.c
processes the data directly out of the flip buffer. It
is not a quick memcpy() into its own working buffer.

I fill the flip buffer a few times an hour at 64Kbps on
this 486-66 while running PPP over ISDN.

-Rob

------- End Forwarded Message