Hi Alan,

On 04/01/13 17:00, Alan Cox wrote:

quoted

Agreed and done. I didn't realise the TTY layer was so prone to
providing lots of itty bitty fragments (even with a single 4k write from
userland). The thing that really hurt was not the allocations but that
each one was written out to the DA separately each incurring it's own
large latency. Using a write buffer makes it a lot faster :)

Think about typing a command and the echo - you get a lot of very small
writes !

Yes. The case I tried was a large write (strace cat /etc/somefile >
/dev/ttyDA2) and strace showed a single large write, but it got to the
driver in chunks of a dozen or so characters. Is that expected to happen?

quoted

quoted

quoted

+	channel_driver->init_termios = tty_std_termios;
+	channel_driver->init_termios.c_cflag =
+	    B38400 | CS8 | CREAD | HUPCL | CLOCAL;
+	channel_driver->flags = TTY_DRIVER_REAL_RAW;

Need to set the speed flags

Do you mean c_ispeed, and c_ospeed? These are set in tty_std_termios,
and they aren't meaningful in the context of this driver anyway, so are
they still necessary?

You update c_cflag to B38400 so you should set c_ispeed/c_ospeed
accordingly. For a virtual interface it really only exists so that
applications have an answer. You want a higher speed like 38400 so that
apps don't try and do clever stuff for low speed links, that is all
really.

Okay, assuming no objections I'll do the following to avoid specifying
an arbitrary speed in the first place (since tty_std_termios sets
c_cflag and c_{i,o}speed to 38400 anyway):

@@ -613,8 +613,7 @@ static int __init dashtty_init(void)
 	channel_driver->type = TTY_DRIVER_TYPE_SERIAL;
 	channel_driver->subtype = SERIAL_TYPE_NORMAL;
 	channel_driver->init_termios = tty_std_termios;
-	channel_driver->init_termios.c_cflag =
-	    B38400 | CS8 | CREAD | HUPCL | CLOCAL;
+	channel_driver->init_termios.c_cflag |= CLOCAL;
 	channel_driver->flags = TTY_DRIVER_REAL_RAW;

 	tty_set_operations(channel_driver, &dashtty_ops);

Thanks
James