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

From: Daniel O'Connor <doconnor_at_gsoft.com.au>
Date: Mon, 18 Feb 2008 22:12:43 +1030
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

Received on Mon Feb 18 2008 - 10:43:07 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:27 UTC