Re: [Bug #14388] keyboard under X with 2.6.31

Alan Cox
2009-10-13T15:59:21Z

> What I was pointing out is that there are a lot of
> "tty_buffer_request_room()" calls, and as far as I can see, all of them
> (or at least a large percentage) are just pure and utter crap.

Almost certainly. When the original conversion was done all the code
which tried to peer into the flip buffer and check what bytes were left
was converted systematically to call request_room() as well in order to
make the conversion easy and reliable. For most devices thats a fairly
naïve conversion as with the new buffering the tty device really
shouldn't care about overruns. If we overrun now it's because we really
do want to dump stuff not because of crappy buffering.

The request_room actually trying to produce big buffers semantic was
added because some of the high speed DMA based adapters (notably 3G USB
ones) would hand large blocks of data over each time at rates upwards of
10-20Mbits. Without that request_room tweak they tended to drop data.

Because of the way they work the DMA buffers are allocated when the URB
is submitted so they can't use prepare_* ops but had to copy in some form.

With those in place we top out at about 40-50Mbits over a USB serial
link, which ought to be enough for anyone sane for the moment.

Your change to tty_insert_flip_string() is irrelevant for any practical
situation simply because the caller has to provide ordering of the blocks
it submits (if it receives 5 bytes and they all queue asynchronously then
it doesn't matter one iota whether tty_insert_flip_string has extra
internal locking "linus" is still going to turn randomly into things like
"sunil" in the serial stream and cause much confusion).

I actually think you should make the tty_insert_flip_string internal
length checking change because:
- It makes the consistency of tty_insert_flip_string clearer to any
future reader
- It's a very very mindbogglingly slight performance win
- It'll no doubt make you feel less grumpy ;)

Alan