From: Jeff D. <jd...@ka...> - 2002-03-03 01:20:34
|
sa...@co... said: > Ok. I'll have another go at this one (if you don't mind :) Heh, feel free. > If I'm not wrong,the mail suggested that there should be a buffer that > every write in the stdio console driver should be directed into, and > write_room should return the appropriate number of bytes left in the > buffer. From my reading of serial.c, that's right. The buffer is attached to the tty as driver_data. > Also, it suggested a write interrupt to push data out once it > was passed further. Instead of an interrupt here, IMHO a simple > wake_up of the process that would've fallen asleep when there was no > room left to write (in the ldisc writer) would do... since I guess > that's what an interrupt handler would get about to doing anyway. 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 that happens, you register for a write interrupt on that file descriptor and stuff 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 normal synchronous writes. IIRC, this will require a little work in the interrupt handling code to allow 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. Jeff |
From: Jeff D. <jd...@ka...> - 2002-03-03 02:45:31
|
sa...@co... said: > If I'm not wrong,the mail suggested that there should be a buffer that > every write in the stdio console driver should be directed into, and > write_room should return the appropriate number of bytes left in the > buffer. This is actually the way the serial driver does it. It stuff the data in a buffer, and then the last thing the write routine does is push the buffer out to the hardware. My suggestion to buffer it only if it won't go immediately is a bit more efficient, but these devices aren't really supposed to be speed demons anyway. Jeff |
From: Jeff D. <jd...@ka...> - 2002-03-03 17:53:17
|
sa...@co... said: > 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). console.c doesn't look like a good model for the UML console driver. There appears to be no hardware buffer that can be filled up, and no need to wait for it to drain before writing more data. The serial driver appears to have this, so that would be the driver to follow. > 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? do_con_write doesn't appear to block. There are a couple schedules in there, but those look like low-latency fixes, not flow control. When you block, there has to be some way of waking up, and an interrupt notifying you that output is possible again is the only sane way to do it. The way I would do this is set up a write IRQ for each console and serial line fd writes either go out directly if possible or into a buffer if not, or always into the buffer and the buffer is attempted to be written at the end of the write if a write returns EAGAIN, the buffer is made to contain the unwritten data and the process downs a semaphore the write interrupt handler ups that semaphore if there is unwritten data in the device's buffer, waking the process sleeping on it so it can write some more if there is no unwritten data in the buffer, the interrupt handler does nothing and returns Jeff |