On Tue, Mar 09, 2010 at 05:29:12PM +0200, Felipe Balbi wrote: > Hi, > > On Tue, Mar 09, 2010 at 10:21:45AM -0500, Alan Stern wrote: > > Shouldn't you fix this, instead of just working around it? A bug like > > that would affect lots of other people too. > > last year I sent an RFC for that which didn't result in much. I'll try > to revive the patch and start over. > > the problem we have now is because ->receive_buf() doesn't return the > amount of data actually received and flush_to_ldisc() believes it can > always flush everything to line discipline. > > my RFC was changing ->receive_buf() prototype to return the amount of > data received (the easiest way) then we could even get rid of the > ->receive_room stuff. I don't recall that RFC, sorry. Care to repost it? > > Can u_serial be changed to support the sort of operation you want (by > > adding a module parameter if necessary)? > > the way TTY handles the buffers is really complicated and there are > waaay too many memcpy() around. Even if I increase the buffer sizes on > TTY and how big amounts of data I bounce, still we will have performance > issues. Where exactly are those performance issues? Do you have oprofile or perf outputs showing it? With the line speeds of USB, I really doubt that a memcpy is the gating factor here. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
