On Tue, May 15, 2012 at 4:08 PM, Alan Cox <alan@xxxxxxxxxxxxxxx> wrote: >> it appears that the software buffer is actually artificially limited >> to 65536 bytes in the tty_buffer_alloc function in tty_buffer.c. I > > Yes although you shouldn't be able to hit this with flow control > enabled. Without flow control we didn't overrun at that level. > > it's really a semantics question - do we count stuff dumped > intentionally without flow control as an overrun. > > I'm not fundamentally opposed to the idea but it is a change of meaning. > > Other views ? > > Alan While I agree on normal use cases this won't be hit due to flow control, I think it is still important to somehow know data was lost in the case where flow control isn't used. Calling it a buffer overrun was the way I thought was most fitting. I'm not sure what the alternatives would be. On a side note, If this isn't considered a buffer overrun I'm also not too sure what the buf_overrun field of the port's icount struct is for. While the "overrun" field is incremented in most drivers to indicate a hardware overrun, the "buf_overrun" field isn't really used. It appears that at least one of the few drivers using buf_overrun (cyclades.c) is interpreting it in the same way that I am, incrementing it when tty_buffer_request_room returns 0. Thanks again, Corbin -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
