[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 11:43:07 UTC 2008


On Mon, 18 Feb 2008, Dag-Erling Smørgrav wrote:
> "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".

Yes..

> > 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 thought it was undetectable but I was willing to learn, I guess I was 
right originally :)

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

I don't see why, I thought that if you had to specify an FD then it 
could be one owned by ktrace rather than the tracing process, however 
that was based on an incorrect assumption so it is not relevant.

-- 
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/cf7f2bc1/attachment.pgp


More information about the freebsd-current mailing list