On Tue, May 15, 2012 at 5:46 PM, Corbin <corbinat@xxxxxxxxx> wrote: > 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. Has anyone had a chance to think about this anymore? We would really like the capability to recognize that data has been discarded, even if it is because no flow control is used and the user is ignoring the port. There are cases, such as with RS-485, where there is no real flow control mechanism is available, so we should not depend on flow-control as always being an option. As Corbin mentioned, there are some other drivers using buf_overrun (as opposed to overrun, which indicates FIFO overruns) for this purpose, but we don't know if this was the original intention of this field. -Jason -- 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
