bugTransport Sample Protocol - Bugs: bug #22190, SIMPLE_TRACE_FUNC destination...

 
 

bug #22190: SIMPLE_TRACE_FUNC destination redefinition

Submitted by:  Robert de Vries <rhdv>
Submitted on:  Thu 31 Jan 2008 01:51:26 PM UTC  
 
Category:  Core Severity:  1 - Wish
Status:  Fixed Privacy:  Public
Assigned to:  Robert de Vries <rhdv> Open/Closed:  Open
Release:  0.8.3 Fixed Release:  0.8.4

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Tue 24 Jun 2008 07:49:23 PM UTC, comment #12: 

Removed xmlrpc/tsp_xmlrpc_client.[ch].
Case closed.

Robert de Vries <rhdv>
Project MemberIn charge of this item.
Thu 06 Mar 2008 07:42:58 AM UTC, comment #11: 

Assigned to RHDV since he did it :=)
After some mail and private phone discussion
I think we are OK to remove (from CVS)
the client side of xmlrpc.

We may resurect the files if the need comes back.

Eric NOULARD <erk>
Project Administrator
Tue 05 Feb 2008 11:47:29 AM UTC, comment #10: 

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.

Eric NOULARD <erk>
Project Administrator
Tue 05 Feb 2008 07:40:44 AM UTC, comment #9: 

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?
Makes sence, since the rpc variant is more efficient in encoding and decoding and no gain of functionality is to be expected from an xmlrpc variant.
So reasoning like this it makes sense to remove it altogether.

Robert de Vries <rhdv>
Project MemberIn charge of this item.
Mon 04 Feb 2008 10:01:38 PM UTC, comment #8: 

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)

Eric NOULARD <erk>
Project Administrator
Mon 04 Feb 2008 09:50:33 PM UTC, comment #7: 

Patch #3:
I have added the missing bits and I have tested the changes.
I have added an attribute declaration that adds printf style argument checking.
I fixed a small typo and removed some test code that was still hanging around.
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. (also in patch).
Then I found out that this file redefines some functions from tsp_client.c so I backed that change out. I have the feeling that this code is still a bit experimental (i.e. unfinished).
I assume that the xmlrpc variants should have different function names.
I also fixed a doxygen warning message (unrelated, but I spotted it and fixed it).

(file #14962)

Robert de Vries <rhdv>
Project MemberIn charge of this item.
Mon 04 Feb 2008 11:16:41 AM UTC, comment #6: 

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.

Robert de Vries <rhdv>
Project MemberIn charge of this item.
Mon 04 Feb 2008 11:02:42 AM UTC, comment #5: 

Hi Frederik,

I will fix the typo.

The missing implementation will be added. Not much work anyway.
I will also test it in EuroSim. (The initial reason for this change).

I had already thought of adding something to restore the format string checking. Thanks for pointing me into the right direction.

My idea of using the TSP_trace_install() function to install a something that does printk() is probably bogus. The base implementation uses printf by default and that will probably fail to load in a kernel.
So your existing solution will probably remain necessary.

Robert de Vries <rhdv>
Project MemberIn charge of this item.
Sun 03 Feb 2008 09:07:17 PM UTC, comment #4: 

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.

Frederik Deweerdt <deweerdt>
Project Administrator
Sun 03 Feb 2008 07:59:26 PM UTC, comment #3: 

This patch has the new trace function and the possibility to install a user defined handler.
I have also removed all newlines from messages that had them, as the  default message handler adds the newline by default.
All instances of STRACE_* have been modified now that it is no longer necessary to have double parentheses.

Robert de Vries <rhdv>
Project MemberIn charge of this item.
Fri 01 Feb 2008 08:16:24 AM UTC, comment #2: 

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

Robert de Vries <rhdv>
Project MemberIn charge of this item.
Thu 31 Jan 2008 10:40:08 PM UTC, comment #1: 

Your patch will be welcomed as usual :))
However note that for a "production" usage
you should build TSP with

USE_STRACE undefined.

This makes almost all messages disappear
but Warning and Error.

In the end I am ok with your proposal and
in fact this is what I did for bb.

Look for bb_logMsg in bb_core.[hc]

Eric NOULARD <erk>
Project Administrator
Thu 31 Jan 2008 01:51:26 PM UTC, original submission:  

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.

Robert de Vries <rhdv>
Project MemberIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #14962:  tsp_strace3.patch added by rhdv (178KiB - text/x-patch - Proposed patch #3: feature request of Frederik implemented + some)
file #14948:  tsp_strace2.patch added by rhdv (172KiB - text/x-patch - Proposed patch #2: all STRACE_* macros are now converted, no uses of tsp_simple_trace.h left)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by deweerdt (Posted a comment)
  • -email is unavailable- added by erk (Posted a comment)
  • -email is unavailable- added by rhdv (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-03-06 erk Assigned toNone => rhdv
    2008-02-05 rhdv StatusNone => Fixed
        Fixed ReleaseUnknown => 0.8.4
    2008-02-04 rhdv Attached File- => Added tsp_strace3.patch, #14962
    2008-02-03 rhdv Attached File#14930 => Removed
    2008-02-03 rhdv Attached File- => Added tsp_strace2.patch, #14948
    2008-02-02 rhdv Attached File- => Added tsp_strace.patch, #14930

    Back to the top


    Powered by Savane 3.5