Trace operations on a particular file/device?

[Roland McGrath]

> Yea, I sort of gathered that strace doesn't attempt to maintain any
> state info.

Indeed.

> True.  But for all the use-cases I run into, simply remembering what
> path was associated with an descriptor returned by open() would
> suffice.  Though I never need it, one could remember descriptors
> returned by creat(), and copy path info when dup[23]() is called as
> well.

Understood.

> Were I to write such a feature, would it be likely to be accepted?
> I'd obviously prefer not to maintain a forked version of strace, but
> it would probably beat writing something from scratch (which somebody
> has proposed).

It's hard to see such things really fitting into strace as it is.  But, the
choice is really up to the community here and their reaction to the details
of changes contributed.  (I might still be authoritative in some sense, but
I am less and less active in strace maintenance now.)

What I had always imagined along these lines is somewhat more grandiose.
That is, something like an XML form of trace output, along with richer
semantics encoded somewhere, that know things like that a particular
argument to a particular call is not just "an int" but is "an open file
descriptor", and that the return value from other calls is not just "an
int" but is "a file descriptor being established" or "a file descriptor
being destroyed".  Then the fancy post-processing would consist of using
the trace records of each establishing/destroying call (i.e. open, close,
dup, etc.) to maintain a table mapping known descriptor values to the past
trace record that last established it (and last destroyed it thereafter),
and annotating the trace record of a call using a descriptor so that the
descriptor argument is a link back to the establishing/destroying record.

> > In Linux, it's possible to deduce some information about descriptors
> > by looking at the /proc/PID/fd/FD symlink target.  strace doesn't do
> > anything like that.
> 
> Yup.  I could attempt to write some sort of front-end that figures out
> file descriptors based on that and then runs strace, but that only
> works for long-running processes and capturing the initial open() and
> ioctl() calls would be difficult.

What I was thinking of was more like hacking strace to look up
/proc/PID/fd/FD at the time of each fd-using syscall.  Then it could
put (3 [/dev/ttyS0], ...) in the trace output.  Or that could be used
to feed a name-matching filter option, etc.


Thanks,
Roland