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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:27 UTC