digest so far? (Re: makesyscalls (moving forward))

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

On Mon, Jun 15, 2020 at 05:16:01PM -0000, Christos Zoulas wrote:
> In article <20200615120806.GB1299%diablo.13thmonkey.org@localhost>, Reinoud Zandijk
> <reinoud%NetBSD.org@localhost> wrote:
> >LLVM code and its fuzzing tools should be in tree anyway so it can be
> >created there on the fly too if requested.
> 
> How about strace, or any other program that wants access to the system call
> table information? Everything in the tree?
> 
> We have an opportunity here to do this better than we have been.  But we are
> trying to answer "how" first, not "why". Let's set up some goals and some
> properties that the new system call description table should have. What
> kinds of output should we be able to generate?

Sounds like a good plan. I tried starting by at least enumerating the users
but the discussion got a bit weildy.

The current info in syscalls.master (and other sources?) seems to be enough to
create syscall.h and syscallargs.h which is impressive. I guess this is the
base usage, to create these structs and constants. We can then, as per request
from David, use it for the in-kernel dispatch C code generation for these
system calls complete with their copyin/copyout.

It would be great if that can be done for the ioctls dispatch code as well and
cover their copyin/copyout stuff, its now all over the place; I think that
would save a lot of hidden bugs. Is there a specification that resembles the
syscalls.master for ioctls? Shouldn't there be one?

A second usage request is to use it for ktrace output decoding etc. I'd
welcome that for the current output is not really that parseable. A full
decoding of system call arguments and results complete with named structs
would greatly improve it. As above, please also do the ioctls, these are quite
incomprehencable in the current form and only a few are decoded IIRC.

A third usage request is to create code for pkgsrc call tracers/dumpers at
compilation time. I guess its for decoding arguments not unlike ktruss/kdump
does.

A fourth usage request is to create interfaces on-the-fly for non-C languages
when compiling the languages from pkgsrc. I presume creating 'C' like stubs or
data structures for them to parse and create code with?

Reading the discussion, I got the idea that the preferred place to store the
definitions for userland usage is internally in the compiled makesyscalls;
compiled with the source tables in BSDSRCDIR/sys and not externally on disc.
This has the advantage that its not corruptable and always compatible with its
sole user and BSDSRCDIR is not needed for usage. This of course has the
downside that that it is installed userland tailored and not tailored to the
running kernel version unless its updated; bit like config(1) dependency on
the format of the config files.

As for the storage of templates etc, those can be stored next to where they
are used. In BSDSRCDIR for kernel work, in a pkg when its doing its thing etc.
Sounds like a logical thing to do.

I must have missed a lot, and missed use cases but I hope this summary will
help the discussion a bit.

With regards,
Reinoud