Robert Watson wrote: > The main missing feature right now, from my perspective, is signal > information, but are there other pieces of detailed process information we > could usefully be displaying? I'm not sure I want to get into teaching > procinfo about generating stack traces, which is something the Solaris > tools can do, but perhaps there are other things we could be displaying.
The functionality I'd use most if implemented would be process trees. But, I wouldn't really call it a missing feature since we already have parent pids in ps(1). I'm not so sure generating a tree is something your tool should do either. A lot of OSes seem to have such a tool, but I don't know if they provide more information than we could put together just using ps(1) and your tool once committed. Think I'll play around with creating a kern.proc.tree, just to see if I can, so a tool could dump it with a few lines, but I think it doesn't belong. > Although it occurs to me that, in many ways, it would be nice to be able to > generate a kernel stack trace for each user thread--often when debugging a > hung process, that's one of the pieces of information I'd really like to > have, as just seeing a generic wchan sleep on a lock is not very useful. That would be invaluable, and isn't functionality we can gain currently by scripting other tools. -- Skip _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
