Re: makesyscalls (moving forward)

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

Small addendum,

On Mon, Jun 15, 2020 at 01:44:19PM +0200, Reinoud Zandijk wrote:
> 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.

LLVM code and its fuzzing tools should be in tree anyway so it can be created
there on the fly too if requested.

Or are the external pkgsrc'd LLVM also to use this? Who can guarantee then
that (1) the syscall file that is installed, (2) the installed generator or
(3) its templates are even compatible or up to date? It would be a blind
guess.

> 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 ...

If one really wants to install the program, you might store it somewhere in
/usr/libexec or the like and the definition file be exposed in /kern then
maybe it could help. The file could be stored compressed internally or be
installed in /stand/$arch/$version with a symlink in /kern

As for config(1), I never understood why it is installed in /usr/bin and is
called with such a generic name, but i guess thats historical.

Reinoud