[uml-devel] Re: [PATCH] Terminal output gets truncated

[Sapan J . B. <sa...@co...>]

// How are you going to know when to wake the process up?  That's what the 
// interrupt handler is for.  Write stuff out until you get -EAGAIN.  When tha
// happens, you register for a write interrupt on that file descriptor and stu
// the unwritten data in the buffer.
// Until the buffer is drained, writing is interrupt-driven.  Stuff data down
// the descriptor until it chokes, wait for another interrupt, and repeat.
// When the buffer has drained, you can disable that interrupt and resume norm
// synchronous writes.
// IIRC, this will require a little work in the interrupt handling code to all
// registration for a write interrupt.  You can probably do this by looking at
// the existing read interrupt code.  If you want help with that part, let me
// know.

Thanks for this! I'll start on the write interrupt method just after this
next clarification-

From my reading of it, the way you've set up the stdio_console driver is 
quite similar to the default
console driver in console.c (i.e, non-bufferred, write room returns a constt
value). The NON-BLOCKING I/O for the whole tty-io write mechanism 
here is implemented in the line discipline
(n_tty.c for example) - which sends a block of data to the console_driver's
writer and simply returns -EAGAIN irrespective of whether it's completed
or not. 

However, the actual writer in the default console driver (console_driver->
do_con_write) in the host kernel BLOCKS write calls...  (i.e., the 
do_con_write function
only returns when the data received has been displayed on the screen). This
block is not too long, since incoming data is already being broken up into
small blocks by do_tty_write in tty_io.c (which I was wrongly duplicating
in my previous patch).

Since this
latency is ultimately encountered anyway in the host kernel, wouldn't it be
superfluous to even try to circumvent it by using the write interrupt 
mechanism?? Which is to say, shouldn't stdio_console->con_write block in
the same way as console_driver->con_write does in the host kernel instead
of providing another "loose layer" with a write interrupt+buffer?

Again, I've tried this patch on my machine (blocking ultimate channel write).
And it works perfectly fine as well...

But then, waiting for your comments :)

-Sapan