In article <20200112210449.accca60...@jupiter.mumble.net>, Taylor R Campbell <riastr...@netbsd.org> wrote: >-=-=-=-=-=- > >[followups on tech-kern] > >I propose to remove the filemon(4) device. > >- Why? filemon(4), which writes records of file-related system calls > to a file, is redundant with ktrace, except potentially for > performance concerns (but I don't know whether anyone has measured). > Our implementation raises some security and correctness concerns by > munging the syscall table, and doesn't compose well. > > We could devote some engineering effort to fixing those issues, but > as far as I know, filemon(4) is not often exercised in NetBSD so it > doesn't seem that fixing filemon(4) is worth the effort. > >- What instead? The attached patch (patch set make-meta-v2.patch; > combined diff make-meta-v2.diff) replaces make's use of /dev/filemon > by ktrace, in meta mode. Other applications could use the same > logic verbatim; if it turns out that there are other applications we > could migrate the logic from usr.bin/make/filemon/filemon_*.c to a > library. > > At sjg's request, there's a compile-time option -- setting the make > variable USE_FILEMON=ktrace vs USE_FILEMON=dev -- to switch between > filemon back ends, since Juniper still uses /dev/filemon on FreeBSD > which has seen more maintenance, security, and performance updates. > (This might also enable future strace, dtrace, &c., back ends.) > > So this patch would still leave a small amount of unexercised code > in our tree, but it's much smaller than before and only in userland, > not in kernel. > >Do you use filemon(4)? Objections? Thoughts?
I am good with the proposal. Thanks for working on this. christos