Francois Gouget fgouget@free.fr writes:
Also, this is why I think it's nice to have the tid on each trace. If not using +relay there is no indication of which thread is issuing the trace.
I'm not opposed to a +tid option to switch on thread information on all traces. But I think +relay should always display the thread info, we will get too many useless traces if it doesn't.
On 10 Apr 2001, Alexandre Julliard wrote:
Francois Gouget fgouget@free.fr writes:
Also, this is why I think it's nice to have the tid on each trace. If not using +relay there is no indication of which thread is issuing the trace.
I'm not opposed to a +tid option to switch on thread information on all traces. But I think +relay should always display the thread info, we will get too many useless traces if it doesn't.
Maybe Uwe's proposal is the way to go then:
On Tue, 10 Apr 2001, Uwe Bonnes wrote: [...]
Probably a silly idea, but what about "+relay" implying implicit "+relay,+tid" and "+relay,-tid" doing what is written?
It would be quite easy to do if I could replace the current 'TRACE_ON(tid)' with: TRACE_ON(tid) || (TRACE_ON(relay) && !TRACE_OFF(tid))
But this supposes that the trace status is tristate: on, off and unspecified. TRACE_OFF would return true only if -tid is specified, and TRACE_ON only if +tid is specified.
Another way to do this would be to hack the code decoding the debugmsg settings to recognize +relay and set +tid at the same time, so that '+relay'=='+relay,+tid'=='-tid,+relay' != '+relay,-tid'. But the last two may be confusing.
IMHO, going the tristate way would be cleaner and should be simple enough.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
Another way to do this would be to hack the code decoding the debugmsg settings to recognize +relay and set +tid at the same time, so that '+relay'=='+relay,+tid'=='-tid,+relay' != '+relay,-tid'. But the last two may be confusing.
what about a +notid channel ? I know it's against the semantics of the channel, but it's close to what you're looking for... A+
On Tue, 10 Apr 2001, eric pouech wrote:
what about a +notid channel ? I know it's against the semantics of the channel, but it's close to what you're looking for...
UGLY!
-- Dimi.
On Tue, 10 Apr 2001, Dimitrie O. Paun wrote:
On Tue, 10 Apr 2001, eric pouech wrote:
what about a +notid channel ? I know it's against the semantics of the channel, but it's close to what you're looking for...
UGLY!
Yes, but it would also be the simplest implementation (overdesign can be ugly too). And if it's the one off hack that it current looks like it is, why not. I propose to just let Alexandre decide which implementation, if any, he thinks would be worth including in CVS.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.
On Tue, 10 Apr 2001, eric pouech wrote:
Another way to do this would be to hack the code decoding the debugmsg settings to recognize +relay and set +tid at the same time, so that '+relay'=='+relay,+tid'=='-tid,+relay' != '+relay,-tid'. But the last two may be confusing.
what about a +notid channel ? I know it's against the semantics of the channel, but it's close to what you're looking for...
Here's a patch that implements the notid solution. Since I have I have it in my tree I might as well post it.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service
-
Alexandre Julliard -
Dimitrie O. Paun -
eric pouech -
Francois Gouget