[Ns-developers] tracing considerations

[Mathieu Lacage]

On Mon, 2007-08-20 at 14:57 -0700, craigdo at ee.washington.edu wrote:

> > indeed. However, there is a GNU extension for that: 
> > __PRETTY_FUNCTION__ does what you want. I think that msvc has 
> > something similar named __FUNCSIG__
> 
> These goes a little overboard and provide the entire function signature.  If
> you use this, you'll see something like,
> 
> virtual bool ns3::Ipv4StaticRouting::RequestRoute(uint32_t, const
> ns3::Ipv4Heade
> r&, ns3::Packet, ns3::Callback<void, bool, const ns3::Ipv4Route&,
> ns3::Packet, c
> onst ns3::Ipv4Header&, ns3::empty>)
> 
> Which looks a lot like noise to me.

The full signature is needed to distinguish between overloaded
functions.
 
> > 2) you could add a function-level logging macro which does 
> > what you do with NS_DEBUG today but with the function name 
> > generated automatically.
> 
> Agree.
> 
> > This will be vastly simpler to implement, and it will be more 
> > portable, although it will require quite a bit of patching to 
> > the code to insert these macro calls.
> 
> Yes.  This is the brute-force and awkwardness approach.  Sometimes it is the
> best approach, though.  I am perfectly content with brute force when it
> works fine and lasts a long time.
> 
> > None of these two options deal with another aspect of the 
> > problem which is that, for every function call, you need to 
> > know more context than just the name of the function/method, 
> > and the value of the arguments:

> > However, what is really useful is the "current node id" 
> > concept. i.e., for each event, there is the concept of the 
> > node within which this event is being executed. Adding 
> > support for this is not totally impossible but it would 
> > require changing the event scheduling API:
> 
> There are other approaches.  Once could build a context string by calling
> into a trace tree, in the same spirit as your trace connectors.

It would be helpful if you could elaborate on this solution.

> 
> For example, some tracefunction executing in a net device would start a
> trace.  The trace code could recursively call into a parent and ask for a
> context string that would be printed out giving something like,
>  
> Node 1: Net Device 3: CsmaNetDevice::TransmitStart (): UID is 8
> 
> Of course, this is a relatively manual approach to getting a trace context;
> but then so is the existing trace facility.
> 
> In a perfect world, I would also like to be able to selectively turn on
> tracing for node 1, net device 3, for example.

Being able to do this would make this solution equivalent in terms of
complexity and functionality to the existing tracing system and, I doubt
you could make it as "simple" to use as the current debugging/logging
facility. i.e., it would require quite a bit of extra work beyond just
using the macro calls and declaring the "logging component" at the top
of the file.
 
> >   i) either you add a set of Schedule methods to the Node 
> > base class which mirror the current Simulator::Schedule methods
> > 
> >   ii) or you add a set of Schedule methods on the Simulator 
> > class which take an extra argument: a node pointer.
> > 
> > I would favor option i) because it clearly is more friendly 
> > with regard to the layering of our codebase.
> > 
> > In both cases, the extra Node pointer argument can be stored 
> > in each event stored in the simulator and be retrieved by our 
> > tracing code with a Simulator::GetCurrentNode () method. The 
> > cases where we would need to call these special scheduling 
> > methods directly is pretty limited because if you call a 
> > normal Schedule method and if the "current node" is non-null, 
> > you can use the "current node" as the node of the scheduled 
> > event. So, you would need to call these methods only from a 
> > few specific locations in the traffic generation code and in 
> > the a few locations in the netdevice channels.
> 
> I'm not sure how this applies to the subject.

It allows you to  get access to the "current node id" if there is one.

Mathieu