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
