> A better solution would be to actually implement the put_char() and
> flush_chars() methods for the console driver. What the console's
> put_char() is called, buffer the characters to be printed. When the
> n_tty line discpline is done sending the characters, it will call the
> flush_chars() method of the tty driver, if the driver has prepared one.
> You can use this method as the cue to flush the output buffer by calling
> con_write().
Exactly, this is what I did first. I added a 256 byte buffer to
struct vt_struct, and added flush_chars() and put_char() calls to the console
driver. This was already faster, but there were some things I didn't like.
First, you could still watch the cursor jump from one 256 byte block to the
next while the screen was redrawn. This could be fixed by making the buffer
larger (say, one page). But that isn't really a good solution either since it
will waste one page for each virtual console. I thought about buffering output
for all consoles in one common buffer but I didn't quite have the nerve to
figure out how this would work with console switching, so I started looking at
the n_tty.c code instead.
> In the long run, opost() should probably be written so that it takes a
> pointer, a from_user boolean, and a count. This will eliminate one of
> the procedure activiations per character that's in the current system.
How about implementing an opost() method for each driver, similar to the way
put_char() is driver dependent? It would take a pointer to a block of
characters as well as a count and would then process the characters as it seems
best (either buffering with put_char() or writing directly with write() ).
This way, you wouldn't need an extra buffer for the console. You'd still have
a default opost() somewhere in n_tty.c for drivers that don't implement this.
Bernd