> I cc'd you because of your recent involvement in other > tty patches/bug fixes and because it's your FIXME comment. > Feel free to ignore and/or let me know you would prefer not to > be bothered. It does seem horribly convoluted and likely to dig bigger long term holes than the one its filling. The tty layer has suffered far too much from "dodging one bullet by being clever and then getting shot at twice more" Bigger question (and one I'm not going to try and untangle at quarter to midnight). Is there any reason that the buffer locking has to be per tty not a shared lock in some cases. My thinking is that we never sit hogging the buffer lock for long periods (even though someone has now made it a mutex which seems an odd performance choice) and it is the deepest lock in the subsystem we take So: if the tty_buffer contained a mutex and a pointer to that mutex then for the pty pairs you could set them to point to the same mutex but default to separate mutexes. At that point you swap all the locks on the mutex to simply lock through the pointer, you don't need the nested hack and there are no special case paths or uglies in the general code. The only special is that pty init paths set the points to both point at the same mutex and no kittens die. Alan -- 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
