On Wed, Nov 18, 2015 at 3:18 PM, matthew green <mrg%eterna.com.au@localhost> wrote:
there's a fairly significant problem with this implementation.
you're only catching callers who use end up going through sy_call()
and that's not the majority. mostly they're called directly from
MD code. so to fix that, you have to update every platform syscall
handler.
FWIW, I did check the archives from 8 years ago when ad@ added the
sy_call() wrapper. It appears that he had already addressed the
several md-specific syscall dispatchers to use the wrapper, so it
seems that we don't need to do anything special. See [1] for the
relevant commit. If you can point out any other code that still
needs to be updated, please do!
[1]http://mail-index.netbsd.org/source-changes/2008/10/21/msg211565.html
i think you're OK here. i did happen to find a couple of weird things
just now:
- filemon(4) is utterly broken. it literally replaces the sysent
values for the current emulation while active. so it has an ugly
obvious problem with runtime usage (particularly at unload.)
however, a much bigger problem is that it adjusts an emulation
that might not be the default one. (32 bit modload of filemon
on a 64 bit kernel, i think, will adjust the netbsd32 sysent.)
so it could break the emulation. this also means that every
other emulation will not be affected and IO will be missed (see:
"utterly broken".)
I think this is worth being a separate PR.
(My original question was about
syscall_establish(9)/syscall_disestablish(9). Now I believe these are
OK; but their users doing bad things is a different story.)