The decision to allocate more storage is decided by an unexpected usage pattern we encountered after the API was designed, which isn't immediately obvious from the device name...
Some of these devices are designed for high-speed PPP. Some of them (in particular on USB) actually move bytes faster than their advertised baud rate. They were not working well. So the buffers were grown. That also adjusted the watermarks, and then things worked better. tty.c 1.128 But was the same good for all ttys? Do consider the calculated watermarks. At the time -- cautiously -- we didn't want to grow the buffers for all the ttys. Maybe that decision can change? This one leads me to think we can: tty_pty.c: pti->pt_tty = ttymalloc(1000000); 992 maximum ptys, that's almost 8MB of memory. But we come back to the watermark calculation... which is why the expected baud rate (maximum baud rate?) is the argument.. Wow. I wrote this code earlier than 1993 when replacing the broken Jolitz rings and creating a proper clist-compat layer... <[email protected]> wrote: > Another trivial code readability comment: > > I see 24 references to this in the code, 20 of which pass 0, and 4 of > which pass 1,000,000 as the parameter. > > Passing 0 defaults to a baud of 115200. The baud determines the qlen, > which is 4096 for 115200 and 8192 for anything larger, so all it is > doing now is selecting between two buffer sizes via magic number > parameters. > > It would probably be appropriate today to just always use 8192 and not > even take a parameter; it doesn't look like the selection between the > two is done in a rigorous way. > > There is also a comment in umodem.c that has an outdated assumption: > /* > * These are the maximum number of bytes transferred per frame. > * Buffers are this large to deal with high speed wireless devices. > * Capped at 1024 as ttymalloc() is limited to this amount. > */ > #define UMODEMIBUFSIZE 1024 > #define UMODEMOBUFSIZE 1024 Yes, that is weird and wrong.
