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 dholl...@netbsd.org