Re: makesyscalls (moving forward)

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Jun 15, 2020 at 09:19:19AM +0200, Martin Husemann wrote:
 > > It seems to me that all of the following is mechanical and should be
 > > automatically generated, beyond what makesyscalls already does:
 > >    - all the code that calls copyin/copyout
 > 
 > It is probably too early and I had too few coffee - but could
 > you point me at an example line of code that does copyin/copyout for
 > syscall args that you think should be replaced with automatically
 > generated code? How much of that generated code would be not from a verbatim
 > C block in the syscall description file?

Glib answer:
   % grep -w copyin kern/*.c | wc -l
        151

A less glib example: line 3186 of vfs_syscalls.c, in stat or more
precisely sys___stat50, has a handwritten call to copyout() to
transfer the stat results back to userspace.

None of it needs to be verbatim blocks in the description file. The
last time I did this the code generator covered everything except argv
blocks, and that was with a pretty simpleminded awk script.

Generating this code has been standard practice in research systems
since the 90s.

The headline benefit of generating it rather than writing and
maintaining it by hand (besides the obvious, lower maintenance costs)
is that it becomes much harder to accidentally mix user and kernel
pointers.

 > >    - compat32 translation for all syscalls and all ioctls
 > 
 > Tricky, but maybe doable. Not sure it will work for all.

I'm pretty sure it will. It's just a matter of reading the type
declarations and generating code that moves from 32 to 64 and back.
The hard part is getting all the type declarations in place so that
the tool can know what needs to be done, but having that is worthwhile
and part of the point of this exercise.

 > >    - compat_otheros translation as well
 > 
 > I have no idea how that would work (or what exactly you mean).

A lot of it is the same kind of logic as compat32: for example the
first half of ultrix_sys_open() is about translating the Ultrix
representation of the arguments to the NetBSD representation. Other
parts are the same as the native NetBSD call handling code, except
using the Ultrix types. Some parts probably can't be done
automatically, like the second part of ultrix_sys_open() that
implements the vintage controlling tty behavior.

 > Rump and anything that needs to serialize/deserialize syscalls are
 > different beasts, and they could benefit from a common syscall
 > "protocol" definition, and maybe in the end it could turn out that
 > we do want to make that description the master source of our own
 > syscall definitions.

The demarshaling done with copyout and the marshaling/demarshaling
done to serialize system calls into a byte stream are the same kind of
thing, even though the representations are different; if you can
generate one, you can generate the others.

 > I have no idea how sanitizers fit in here.

They need wrapper functions for system calls, which need to know much
the same things as marshaling/demarshaling code.

 > Maybe start with the basics and explain things from ground up
 > before diverging into the hard issues (like the name and install
 > location).

Well... sure except now I'm not sure where to start. Didn't want to
start with lengthy explanations of things everyone already knows. :-/

-- 
David A. Holland
dholland%netbsd.org@localhost