Do you mean that the c variant of the client side of the xmlrpc interface is not meant to be used, but rather the plain old rpc variant?

Short answer is YES.
I go on list for longer answser because it's
too off topic regardign SIMPLE_TRACE_FUNC.

xmlrpc support is a joint work of
Frederik DEWEERDT and Stephane (GALLES).

It should work :=).
But may be not for the client side.

The idea was to be able to have both ONC-RPC and XML-RPC
command channel on the provider-side but it seems
unecessary to have both on client side.

>I have also changed some remaining STRACE_IO's to >STRACE_DEBUG_MORE (tsp_xmlrpc_client.c)
>I then tried to compile that code, but I had to fix some more >stuff.

xmlrpc/tsp_xmlrpc_client.c is not compiled any more in
the mainstream TSP.
(look at the tsp/core/CMakeLists.txt)
there is "only":
xmlrpc/tsp_xmlrpc_server.[hc]
xmlrpc/tsp_xmlrpc_util.[hc]

I think we may remove that file unless someone find it
is useful?

I did not review the STRACE patch but as Frederik did
I am OK with a commit (only for the STRACE part)

Another thing that I forgot to mention is that I now print error messages from the strtol() function to stderr using a fprintf().
It is probably better to use the trace function itself, not TSP_trace(), but the installed trace function.

It might also be nice to have a function that allows the setting of the trace level (global now) using a function call.
This is of course only truly useful in case USE_STRACE is defined.

Maybe redundant, but please note that tsp_simple_strace.h in tsp/core/include is replaced by tsp_common_trace.[ch] in tsp/core/common.

Hello Robert,

The patch #2 looks good, thanks. Two minor remarks:
- in level_name() there's a typo when returning "ERRROR" instead of "ERROR"
- The TSP_trace_install function's implementation appears to be missing

... and a feature request :). Could you add
_attribute_ ((format (printf, 5, 6))) to TSP_trace's declaration in tsp_common_trace.h ? #if _GNUC_ >= 3 is needed, IIRC.

It is exactly the warning and error messages that end-users are interested in when something goes wrong.

In my case the provider failed to register itself with rpcbind due to the fact that all twenty (or so) program numbers were already taken. The only message that arrived at the user was that the provider failed to start. The interesting stuff went to a hidden logfile (about that you should use tsp_rpc_cleanup).

My idea is to have a generic function:
void tsp_trace(int level, const char *src, const char *func, const char *fmt, ...)

This function calls internally the default output function unless it is overridden by the user by his own function.
That function would look like this:
void user_def_trace(int level, const char *src, const char *func, const char *fmt, va_list args);

There is a little snag due to the varargs, and using macros like STRACE_ERROR like how they are used now, but either the STRACE_ERROR etc. are converted to functions or I can use the varargs features of the macro preprocessor (the latter being a C99 feature and it has my preference).
However, in case people are still using compilers that are more than 10 years old, I have to convert every STRACE_* to a function.
All GNU C compilers can handle this fine.

This solution would remove the need for the specialized bb_logMsg(). You would just use the normal STRACE_ macros and install a user-defined msg handler instead (or redefine the standard msg handler to the printk variant).



Thanks for helping us tracking bugs in TSP. Be sure you send all
the log & context on the problem.
Please be sure will do our best for correcting it.

Regards,
TSP admin

It is currently impossible to redirect the error output of the SIMPLE_TRACE_FUNC mechanism.
I propose to make the SIMPLE_TRACE_FUNC macro an actual function that calls another function to do the actual outputting of the message.
The problem is now that the output appears on stdout. This is fine if you are running a command line application. But it isn't if you are running an embedded application that doesn't have a console.

I will propose a patch for this later on.