[src] cvs commit: src/include unistd.h src/lib/libc/sys readlink.2 src/sys/compat/freebsd32 syscalls.master src/sys/kern syscalls.master vfs_syscalls.c src/sys/sys syscallsubr.h

Daniel O'Connor doconnor at gsoft.com.au
Mon Feb 18 04:43:59 UTC 2008

On Mon, 18 Feb 2008, Giorgos Keramidas wrote:
> >>> However, you still keep the file around which can be rather space
> >>> consuming :(
> >>
> >> Yes, but it also means you can do offline analysis later. :)
> >> Tradeoffs either way.
> >
> > Yes, but being able to specify stdout to ktrace would be really,
> > really nice..
> Specifying stdout may be a bit tricky, since the traced application
> may be using the same stream to print output.  The same is possible
> with stderr, but may be a tiny bit less likely.

I didn't realise that the file descriptor used to write tracing data out 
was 'owned' by the process being traced, I always thought ktrace did.

> It is probably easy to add an -F flag to ktrace/kdump which would
> inhibit the check for a `regular' file, so you could then write:
> 	( ktrace -aF -f /dev/stdout ls ) | \
> 	  kdump -F -f /dev/stdin
> 	( ktrace -aF -f /dev/stderr ls >/dev/null ) 2>&1 | \
> 	  kdump -F -f /dev/stdin
> But the first will probably fail when kdump tries to parse the output
> of ls(1), and the second may fail in a similar manner when kdump
> tries to parse an error message like a ktrace record.
> This sort of difficulty in separating the output of the traced
> process and the ktrace records themselves is probably at least part
> of the reason why nobody has done it yet.

I did have a look at the source and the file opening etc is handled by 
the kernel but I am not sure who 'owns' that file descriptor.

If, as you suggest, it is the process being traced then yes it would 
cause problems.

I guess it couldn't be moved to ktrace without rearchitecting how 
ktracing works so the ktrace process sticks around writing stuff out to 

Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080218/e9d5e1f5/attachment.pgp

More information about the freebsd-current mailing list