| Submitter | Ed Swierk |
|---|---|
| Date | 2010-06-23 06:43:58 |
| Message ID | <1277275438.20870.8.camel@localhost.localdomain> |
| Download | mbox | patch |
| Permalink | /patch/1546/ |
| State | Accepted |
| Headers | show |
Comments
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.
Patch
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; }
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> ---