On Sun, Jun 14, 2020 at 11:59:54PM +0200, Johnny Billquist wrote: > > "usr.bin/makesyscalls" sounds good to me. > > Uh? usr.bin is where stuff for /usr/bin is located, right? Anything there > should be pretty normal tools that any user might be interested in. Don't > seem to me as makesyscalls would be a tool like that? > > Possibly some sbin thing, but in all honestly, wouldn't this make more > sense to have somewhere under sys? Don't we have some other tools and bits > which are specific for kernel and library building?
So this was, in fact, a discussion I was intending to provoke, because right now we have no place to put tools that are part of the system build but don't make any sense to install in /usr, and that seems like a gap. However, Kamil convinced me that there will be external users of this thing. As I mentioned in the original mail, apparently the llvm sanitizers already have a netbsd-specific script that tries to read the existing syscalls.master, and any future sanitizer-like thing will need something similar if we don't provide a facility. Having 3rd-party sources like this groping in our tree trying to read an internal file whose format and semantics we don't support is not the right way. Meanwhile it doesn't belong in sbin because it doesn't require root, nor does doing something useful with it require root, and it doesn't need to be on /, so... usr.bin. Unless we think libexec is reasonable, but if 3rd-party code is going to be running it we really want it on the $PATH, so... -- David A. Holland [email protected]
