Klemens Nanni wrote:
> I wanted to quickly debug some program without actually dumping to disk
> by using FIFOs, however ktrace(2) wouldn't accept anything but regular
> files.
>
> Are there any pitfalls or limitations I am currently not aware of that
> justify this strict behaviour?
oh, neat, i've actually really wanted something like this for a while. i was
trying to find a way to make it an arbitrary fd, but this seems like a much
smaller diff.
i don't think there should be problems. i haven't checked the code recently,
but it should already handle disk full, etc. situations, so if the reader
stops it just means events get thrown away. the traced process shouldn't
block. but that's something to confirm and test.
>
> $ ln -s some.file link
> $ ktrace -a -f link echo foo
> ktrace: link: Too many levels of symbolic links
>
> $ mkfifo fifo && cat fifo >/dev/null &
> $ ktrace -a -f fifo echo foo
> ktrace: fifo: Permission denied
>
>
> With this tiny patch ktrace(2) allows appending to FIFOs, which enables
> me to do the following:
>
> $ mkfifo ktrace.out && kdump -l &
> $ ktrace -a echo foo
> foo
> 1903 ktrace RET ktrace 0
> 1903 ktrace CALL
> execve(0x7f7ffffe6d50,0x7f7ffffe72e8,0x7f7ffffe7300)
> [...]
> $ ktrace -a echo bar
> bar
> 94065 ktrace RET ktrace 0
> 94065 ktrace CALL
> execve(0x7f7ffffe2280,0x7f7ffffe2818,0x7f7ffffe2830)
> [...]
>
>
> Feedback? OK?
>
> Index: kern_ktrace.c
> ===================================================================
> RCS file: /cvs/src/sys/kern/kern_ktrace.c,v
> retrieving revision 1.91
> diff -u -p -r1.91 kern_ktrace.c
> --- kern_ktrace.c 14 Feb 2017 10:31:15 -0000 1.91
> +++ kern_ktrace.c 20 Jun 2017 22:01:56 -0000
> @@ -428,7 +428,7 @@ sys_ktrace(struct proc *p, void *v, regi
> vp = nd.ni_vp;
>
> VOP_UNLOCK(vp, p);
> - if (vp->v_type != VREG) {
> + if (vp->v_type != VREG && vp->v_type != VFIFO) {
> error = EACCES;
> goto done;
> }
>
