This code is buggy; I have to nak it in its current form. The problem (which is the same one that I couldn't solve in a pretty way) is that uart_insert_char() allocates memory and generally does a lot of might-block things. This is Not Okay in the middle of a console printf. There are three ways I've thought of to deal with this. Peter, you have both strong and well-informed opinions on code style, so I'd appreciate your input on which is best (or maybe you have a fourth idea). 1) Pass a "may_allocate" flag down to serial8250_rx_one_char and uart_insert_char. This is the most obvious, but the previous iteration of this patch caught a lot of flak for a similar magic bool flag, so I don't think this one will fly. 2) Have serial8250_rx_one_char return the character (actually, probably lsr << 8 | ch, or -1 if there's no character available) and have the callers deal with storing it. 3) Add a "can you guarantee that uart_insert_char() can store one character without allocating" call, and add that to the conditions for calling serial8250_rx_one_char in rx_while_wait_for_xmitr(). I just thought of a particularly clever and efficient way to handle flags in the tty_buffer, which makes the third option quite attractive. Rather than have a TTYB_NORMAL flag on each tty_buffer, a tty_buffer is X normal characters, followed by Y flagged characters, followed by Y flag bytes, where X + 2*Y = buffer->size. It's the same two cases that are in the code now, but the dividing line is within each tty_buffer rather than between them. It avoids the need to ever leave a tty_buffer short. As long as there are two bytes free *or* a non-empty free list, we can guarantee the ability to buffer one character. Peter, any thoughts? -- 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
