RFC: path display and path filtering features.

[Dmitry V. Levin]

On Wed, Feb 16, 2011 at 04:29:49AM +0000, Grant Edwards wrote:
> On 2011-02-15, Dmitry V. Levin <ldv at altlinux.org> wrote:
[...]
> > The approach to track descriptors is much more complicated (and
> > therefore more error-prone) and less reliable than readlink-based
> > because of all details that have to be taken into account to trace
> > descriptors properly.
> 
> True.
> 
> > The overhead of readlink-based method is one syscall per descriptor,
> > that's hardly noticeable compared to multiple syscalls strace already
> > does to parse a single syscall made by the target process.
> 
> I was wondering about that.  I didn't realized until later that it
> takes an additional system call for each "indirect" parameter, as well
> as a context switch on both entry and exit of the system call.  Adding
> a read of /proc is probably negligible.  It would limit usage to
> systems with /proc enabled.  That's probably not a big issue unless
> you're talking about small embedded systems.  It would be nice if the
> read didn't have to happen twice (once when deciding to display the
> syscall, and a second time when displaying it), but trying to cache
> the value also introduces complications.

Even with these complications, readlink-based approach seems to be more
reliable and easy to implement and support.

Another issue is how to match paths reliably without introducing code into
every parser function.  The approach implemented in your pathtrace_match()
is not capable to handle syscalls that take several pathname arguments
like rename(2), or pathname argument along with descriptor argument like
openat(2).  Possible solution could be extending struct sysent with more
generic information about syscalls, e.g. with two 8-bit bitsets describing
pathname-like and descriptor-like arguments.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20110216/12f93f1a/attachment.bin>