stderr is for error messages, right?

Development Boards MicroMod
1

Dominic,

If you agree, could you please implement sg similar into log.c:

"

void log_printf(enum log_levels level, const char *file, int line, const char *function, const char *format, …) {

va_list args;

char buffer[512];

if (level > debug_level)

return;

va_start(args, format);

vsnprintf(buffer, 512, format, args);

if (log_output != NULL){

fprintf(log_output, “%s %s:%d %s(): %s\n”, log_strings[level], file, line, function, buffer);

fflush(log_output);

}else{

if(level==LOG_ERROR){

fprintf(stderr, “%s %s:%d %s(): %s\n”, log_strings[level], file, line, function, buffer);

fflush(stderr);

}else{

fprintf(stdout, “%s %s:%d %s(): %s\n”, log_strings[level], file, line, function, buffer);

fflush(stdout);

}

}

va_end(args);

}

"

and also rem out or delete setting log_output to stderr at init:

"

int log_init(struct command_context_s *cmd_ctx) {

/* set defaults for daemon configuration, if not set by cmdline or cfgfile */

if (debug_level == -1)

debug_level = LOG_INFO;

// if (log_output == NULL) {

// log_output = stderr;

// }

return ERROR_OK;

}

"

2

Hello Albert,

they only change we could make is to have the use of stderr or stdout configurable.

The meaning of “ERROR”, “WARNING”, “INFO” and “DEBUG” is somewhat arbitrary. I try to use ERROR for fatal errors, WARNING for things that might affect correctness of the target state, INFO for general-interest stuff and DEBUG for messages mostly useful for debugging the OpenOCD itself. But these messages only have a meaning when they all appear in order - redirecting some to a file and some to the screen makes the debug output useless for me.

Maybe if you could explain why you want such a change I would be able to suggest other ways to achieve the same goal.

Regards,

Dominic

3

Dominic,

The explanation why I wish to have the error messages and only the error messages sent to the stderr, and the rest to the stdout…

I start openocd daemon from a script which grabs the stdout and the stderr output streams of openocd. The script is capable of doing some health check of openocd during its life by checking the output streams.

Instead of writing a parser to interpret different output messages (like looking for “error” string in the message), I wish to simplify my script to detect a “fatal” error whenever sg was received from the stderr stream.

Currently everything is going through the stderr.

If you don’t want to use both streams, I would still prefer the use of stdout and I would try to detect an error, by looking for “error” in the stream.

Actually the error messages, at current revision, are still not sending the “error” text with every error message yet.

Best Regards,

Albert

4

Hello Albert,

I really don’t want to split the output into several streams for the above reason, so you’ll have to look for “ERROR:” to identify fatal errors. In a POSIX environment I would just pipe std[out|err] through “grep ERROR” - that would filter everything else out.

I’ll look into some other GNU programs to see what they use (stdout or stderr) for the purpose of log output.

I’m not sure what you mean by

Actually the error messages, at current revision, are still not sending the “error” text with every error message yet.

If your talking about the log output:

All errors use the ERROR macro to output something to the log.

If you’re talking about the telnet messages:

What I meant in the other thread was that if you’d like this change I would include a patch (diff against SVN head) - the change isn’t important to me, but I don’t mind adding it if it helps you, but I don’t have time to go through all parts of the code myself.

Regards,

Dominc

5

Dominic,

After rethinking, I think it is acceptable to send messages other than error messages (even success notifications!) to the stderr stream, which is normally for error messages. Especially because each message type can be easily identified. You are right, the telnet messages are the ones, which cannot be identified easily (why not?). Couldn’t you implement macros for telnet error, warning etc messages similar to the macros which currently write to stderr?

Stdout vs stderr really does not matter. Don’t change if it is not broken.

Albert

6

Hello Albert,

I’ve checked a few other programs, and it seems quite common to use stderr for all kinds of messages. The log messages have the prefixes because they have different levels, and the user (and myself, too) can select what messages get printed (ERROR, +WARNING, +INFO, +DEBUG). During normal operation, I usually have INFO, but sometimes, I use DEBUG, to see what the OpenOCD is doing. A user would normally use DEBUG only when I ask him to provide me a logfile. Adding prefixes to these messages was easy, and makes it easy to see what’s DEBUG and what not.

Regarding the telnet messages - of course it wouldn’t be a problem adding prefixes to each message (where appropriate - some commands don’t have an immediate success/failure output, other’s are pure informational), but so far there was no reason for this. The telnet messages are for user interaction, and a user is capable of understanding what each message says.

So far, you’re the only one I know who’s using a script to control the telnet interface. If you’d like to prefix telnet replies with sucess/error, I’m open to integrate a patch that adds this functionality in a consistent way that doesn’t interfere with the telnet interface’s normal purpose, i.e. user interaction. But this functionality isn’t important to me, nor was there anyone else requesting something like it, so you’ll have to write the necessary changes yourself, and provide a patch against current SVN HEAD (just do a “svn diff” on a tree with the minimum changes required).

I don’t think I understand what your script’s purpose is - you say you’re starting the OpenOCD daemon from it, but what is it doing then? Do you use GDB to debug a target? Or does the script remote control the OpenOCD to execute flash or test operations for example?

Regards,

Dominic

7

Hi Dominic,

What is the purpose of scripting OpenOCD?

I have developed a test sequencer, similar to National Instrument’s TestNet, to automate test execution. The test targets are different boards with different CPU-s.

At the beginning of the test sequence the tester downloads the debug fimware to the flash of the CPU and runs the test, at the end of the sequence the tester downloads the production firmware to the target. The tester automatically runs OpenOCD with the right cfg file, and sends telnet commands to it and shuts it down at the end.

Because user interaction has to be kept to minimum it is all controlled by scripts.

Albert