[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
peterjeremy at optushome.com.au
Mon Feb 18 11:05:25 UTC 2008
On Mon, Feb 18, 2008 at 03:13:35PM +1030, Daniel O'Connor wrote:
>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.
Unlike truss/ptrace type tools, ktrace just sets a flag in the process
that tells the kernel to generate ktrace records. This is more obvious
when you use the 'ktrace -p PID' form.
On Mon, 18 Feb 2008, Giorgos Keramidas wrote:
>> 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
I don't think stdin/stdout is practical here but supporting named
pipes sounds like it would be useful.
>I guess it couldn't be moved to ktrace without rearchitecting how
>ktracing works so the ktrace process sticks around writing stuff out to
And from what I've seen of the innards of ktrace, the re-architecting
would be quite significant.
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080218/49873c9e/attachment.pgp
More information about the freebsd-current