Currently messages like "Writing flash chip..." that don't end with a newline are buffered until the operation is complete, unless the particular write function generates status output in the meantime.
Flushing stdout after each message ensures that the message appears immediately.
Signed-off-by: Ed Swierk eswierk@aristanetworks.com
--- Index: flashrom-0.9.2-r1057/cli_output.c =================================================================== --- flashrom-0.9.2-r1057.orig/cli_output.c +++ flashrom-0.9.2-r1057/cli_output.c @@ -47,5 +47,6 @@ int print(int type, const char *fmt, ... va_start(ap, fmt); ret = vfprintf(output_type, fmt, ap); va_end(ap); + fflush(output_type); return ret; }
Am Dienstag, den 22.06.2010, 23:43 -0700 schrieb Ed Swierk:
Currently messages like "Writing flash chip..." that don't end with a newline are buffered until the operation is complete, unless the particular write function generates status output in the meantime.
Correct. This should be fixed, but...
Flushing stdout after each message ensures that the message appears immediately.
...if you want to flush immediately after each message, you better turn off buffering of stdout alltogether using setvbuf in the startup code, I think.
Regards, Michael Karcher
On Thu, Jun 24, 2010 at 12:34:33AM +0200, Michael Karcher wrote:
Am Dienstag, den 22.06.2010, 23:43 -0700 schrieb Ed Swierk:
Currently messages like "Writing flash chip..." that don't end with a newline are buffered until the operation is complete, unless the particular write function generates status output in the meantime.
Correct. This should be fixed, but...
Done in r1349 for now.
Flushing stdout after each message ensures that the message appears immediately.
...if you want to flush immediately after each message, you better turn off buffering of stdout alltogether using setvbuf in the startup code, I think.
Hm, maybe, but then again we should check how portably you can disable buffering (on DOS, win, freebsd, etc). The fflush() is most likely to work everywhere I think (but I haven't tested it).
Uwe.
Am Sonntag, den 19.06.2011, 19:29 +0200 schrieb Uwe Hermann:
Flushing stdout after each message ensures that the message appears immediately.
...if you want to flush immediately after each message, you better turn off buffering of stdout alltogether using setvbuf in the startup code, I think.
Hm, maybe, but then again we should check how portably you can disable buffering (on DOS, win, freebsd, etc).
The fflush() is most likely to work everywhere I think (but I haven't tested it).
fflush just cares about the buffer in libc, not about any buffering in the OS (not that I am aware of that any OS buffers screen outputs, though). if you just care about the libc buffer, there is no problem with setvbuf, as this function is ANSI, and as it is just about when libc passes the data to the OS, perfectly portable. I remember having seen this function already in Turbo C 2.0 (And that is years before Turbo C++ 2.0)
Regards, Michael Karcher
The fflush() is most likely to work everywhere I think (but I haven't tested it).
fflush just cares about the buffer in libc, not about any buffering in the OS (not that I am aware of that any OS buffers screen outputs, though). if you just care about the libc buffer, there is no problem with setvbuf, as this function is ANSI, and as it is just about when libc passes the data to the OS, perfectly portable. I remember having seen this function already in Turbo C 2.0 (And that is years before Turbo C++ 2.0)
Looks like it doesn't work with libpayload's c library.