Re: [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> writes:
> Giorgos Keramidas <keramida_at_freebsd.org> writes:
> > 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.

ktrace does absolutely nothing other than enable tracing and exec the
application.  The 'k' in "ktrace" means "kernel".

> 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.

There is no file descriptor.  There is a vnode in the kernel which is
not listed in the traced process's file table.  This is the whole point
of ktrace: it is undetectable by the traced process.

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

...which would make it just as useless as truss, since it would (among
other things) change the way job control works for the traced process.

DES
-- 
Dag-Erling Smørgrav - des_at_des.no