Re: makesyscalls (moving forward)

[Reinoud Zandijk <reinoud%NetBSD.org@localhost>]

On Sun, Jun 14, 2020 at 09:07:45PM +0000, David Holland wrote:
> As I mentioned a few days ago the reason I was prodding
> makesyscalls.sh is that I've been looking at generating more of the
> system call argument handling code.
...
> This raises two points that need to be bikeshedded:
> 
> (1) What's the new tool called, and where does it live in the tree?
> "usr.bin/makesyscalls" is fine with me but ymmv.

What about not installing it at all? Its only going to be used during
definition updates or fixes. Compare it to the pcidevs.h and pcidevs_data.h
creation only this time it creates the relevant kernel/rump/fuzzer files. The
program can optionally be compiled and linked in /tmp and then called from
there to create all the variants using the templates or just be created in
place and cleaned up later.  No need to install it in base. The resulting
files can then be committed as `regen' just like the pcidevs variants.

> (2) What is the installed syscall description file called and where
> does it go? It is likely to be derived from (i.e., not the same as)
> syscalls.master. It isn't a C header file so it doesn't belong in
> /usr/include. It isn't necessarily particularly human-readable. My
> suggestion would be to add a directory in /usr/share for API
> descriptions and put it there, something like maybe
> /usr/share/api/syscalls.def.

I wouldn't install the file in the FS; kernel and userland are often out of
sync, maybe even versions apart with say NetBSD-8 userland but NetBSD-current
kernel. If anywhere, request the data from the kernel by exposing it in /kern.
Exposing it one way or another might be an attack vector too ...

With regards,
Reinoud