Re: makesyscalls (moving forward)

[David Holland <dholland-tech%netbsd.org@localhost>]

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
dholland%netbsd.org@localhost