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