On Sep 30, 2008, at 8:03 PM, Paul Macknee wrote: >> Perhaps this would be an opportunity for a third party to build >> some layered >> software to implement your suggestion. That is, one could write a >> program >> that consumed CTF data to generate a D script that did what you >> described. > > Great, I'm a third party.. ;) From my point of view, I think that > generating it from headers might be easier, especially if I could > program it in a dtrace function of my own design, and just look at > the headers i'm most interested in.
Why would you want to do this as a "dtrace function"? This seems like a preprocessing step that you'd want to do statically rather than at runtime. If DTrace were to support functionality of a "dumper" as you suggest, it would do so by statically examining the enabled probes and emitting the appropriate tracing commands. > Come to think of it - exactly how could you scale up such a > generated program that doesn't use user function calls? Suppose I > wanted to use the intelligent copystr in my own program in a myriad > of places - are you really suggesting that having an interpreter > which takes user-level functions and expands them in my source code > is the best way to do it? Potentially, but it depends on what you want. > I think you guys should just bite the bullet and make user-level > functions.. That's a pretty complicated suggestion, and one that's unlikely to be possible in the way that you're imagining. There's an existing RFE for an equivalent to mdb's ::print functionality that would pretty-print a datum according to its time. This would perhaps be a step towards what you're suggesting. Adam -- Adam Leventhal, Fishworks http://blogs.sun.com/ahl _______________________________________________ dtrace-discuss mailing list [email protected]
