>> In fact, one could actually look at what John released >> *before* posting to this list and making oneself look silly. It's an >> idea. > > Uriel is renowned for demanding tools to be released on principle, > without him having any practical need for them. He lands up sounding > like a peevish, ungrateful child who just wants more sweets even > though his hands are already full. > > Far from him to actually do some checking first. What could he > possibly need with devtrace anyway? > > That said, is there any reason why devtrace is not part of the > distribution and are there plans to incorporate it? > > ++L
Answering the last question: devtrace has only been compatible with the current kernel for a few weeks, which I've spent testing and cleaning up the code a bit. Right now, I'd object to including devtrace in the distribution because of all the #pragma's it tosses around in 9/pc, 9/port, and even libc. Also, it currently replaces the *old* profiling system--that's why the assembly functions are called _profin and _profout even though they call tracein and traceout in devtrace.c (and everything else in the code is called "trace" rather than "profile"). I hacked the linker so it could take a -t flag and insert _tracein and _traceout; if we were to put it in the distribution, we could replace all my "#pragma profile 0" lines with "#pragma trace 0", which would allow you to still use the old profiling system without interference. It would be a bit of work but definitely feasible if there's interest. John
