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

On 2008-02-18 10:04, Daniel O'Connor <doconnor_at_gsoft.com.au> wrote:
>On Sun, 17 Feb 2008, John Baldwin wrote:
>>On Friday 15 February 2008 08:23:33 pm Daniel O'Connor wrote:
>>>On Sat, 16 Feb 2008, John Baldwin wrote:
>>>>> That's a pretty big advantage :)
>>>>>
>>>>> Also, ktrace can't write to a pipe which means you need to
>>>>> run/process rather than 'stream'.
>>>>
>>>> kdump -l.
>>>
>>> Ahh nice!
>>>
>>> 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..

Hi Daniel,

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.

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.

- Giorgos