Re: makesyscalls (moving forward)

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

On Mon, Jun 15, 2020 at 02:06:00PM +0200, Kamil Rytarowski wrote:
> On 15.06.2020 13:44, Reinoud Zandijk wrote:
> >  No need to install it in base. The resulting files can then be committed
> >  as `regen' just like the pcidevs variants.
> 
> I disagree as we don't want to pull ${BSDSRCDIR} dependency for users, for
> building an application.

Lets try to make it clear then: who are the users?

1) Kernel syscall and compat (module) code; only when updating calls

2) ktrace (and friends) system calls decode. That would greatly increase
readability ! Esp. if passed arguments could be automatically dumped too.

3) (llvm) fuzzers for testing; this is intree too so no big deal

4) some syscall bashing tools for testing etc. They are tailored anyway so
using a $BSDSRCDIR specfic program that is not installed is not that relevant.

But what else? There are IMHO no other valid users.

> This utility shall receive ATF testing and thus shall be part of $PATH.

ATF testing sounds like a good idea; but does an utility have to be installed
to be able to test code?

Also the generated files need to be updated in the kernel source tree and are
tightly coupled to the kernel code templates.

> Putting it to /kern would be bad as we will gain another kernel ABI
> dependency and this program won't be usable in TOOLDIR neither when working
> with different target NetBSD release than the developer's computer.
> 
> I personally think that the definition file shall be embedded directly into
> the program to avoid any issues with incompatible script version vs
> makesyscalls(1) program.

You got a point there, and embedding it would make sense yes; but i still
wouldn't install the program or its definition files as its kernel source
version dependent and when building tools etc. $BSDSRCDIR is obviously
available anyway.

Reinoud