RFC: path display and path filtering features.

[Dmitry V. Levin]

On Thu, Feb 24, 2011 at 09:25:13PM +0000, Grant Edwards wrote:
> >>  3) Compare stored paths against path arguments.
> >
> > Thanks, it works.  I think it could be merged after some cleanup and
> > re-indentation.
> >
> >> Things on the possible (near-term) todo list:
> >> 
> >>  1) Canonicalize relative path args based on /proc/$pid/cwd
> >> 
> >>  2) Handle combination fd/path args such as those passed to openat()
> >
> > Let's try simple combination without path canonicalization in both cases.
> 
> OK.
> 
> > I'm still not quite comfortable with applying realpath(3) to user
> > data, from security PoV.  Maybe this kind of canonicalization should
> > be enabled only when requested explicitly, e.g. via special option.
> 
> That wouldn't be difficult.  Is it something we want to do now?

Let's cleanup and merge already written code first.

> >> --- a/desc.c
> >> +++ b/desc.c
> >> @@ -309,7 +309,8 @@ int
> >>  sys_fcntl(struct tcb *tcp)
> >>  {
> >>  	if (entering(tcp)) {
> >> -		tprintf("%ld, ", tcp->u_arg[0]);
> >> +		printfd(tcp,tcp->u_arg[0]);
> >> +		tprintf(", ");
> >>  		printxval(fcntlcmds, tcp->u_arg[1], "F_???");
> >>  		switch (tcp->u_arg[1]) {
> >>  		case F_SETFD:
> >
> > In this and other similar cases, a comma between function arguments is
> > necessary.
> 
> While I understand that sentence, I don't undestand how it is meant as
> a comment on the diff above it.  Can you explain?

-		printfd(tcp,tcp->u_arg[0]);
+		printfd(tcp, tcp->u_arg[0]);

> >> diff --git a/pathtrace.c b/pathtrace.c
> >> new file mode 100644
> >> index 0000000..70babff
> >> --- /dev/null
> >> +++ b/pathtrace.c
> >> @@ -0,0 +1,304 @@
> >
> > I suggest to apply code indentation of quota.c for new files.
> > This file is indented very different from quota.c
> 
> I planned on re-indenting it after I was done working on it.  Since I
> haven't found any tools/settings that produce the indentation you
> desire, it's pretty difficult for me to maintain your desired
> indentation while working on files.  After we've decided on the actual
> code I'll fix the indentation.  Is there a set of options for ident or
> astyle or some other tool that will produce the indentation you want?

For new files, I use GNU indent with attached config, the result it produces
is very close to my preferred coding style.

> >> @@ -1256,7 +1274,7 @@ proc_open(struct tcb *tcp, int attaching)
> >>  #else /* FREEBSD */
> >>  	/* just unset the PF_LINGER flag for the Run-on-Last-Close. */
> >>  	if (ioctl(tcp->pfd, PIOCGFL, &arg) < 0) {
> >> -	        perror("PIOCGFL");
> >> +		perror("PIOCGFL");
> >>  		return -1;
> >>  	}
> >>  	arg &= ~PF_LINGER;
> >
> > In this and other cases, please avoid re-indentation of unrelated code.
> 
> I've been trying to, but it's difficult when the indentation is so
> inconsistent (different styles in different files, spaces in some
> places within a file tabs in others).

I agree, this is inconvenient.

> I don't know about others, but it I would find it a lot easier to work
> on the source files if they all had a consistent, standard indentation
> style that could be produced by a tool like indent or astyle (I don't
> particulary care what standard or what tool).

Yes, adding new code would be easier.  Fortunately, git blame has -w
option, so one can hope that history tracking won't suffer very much from
total code re-indentation.


-- 
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/20110225/6af52b73/attachment.bin>