How to get filename of an open file descriptor

[Skip Ford]

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