On Mon, Jun 15, 2020 at 05:16:01PM -0000, Christos Zoulas wrote: > In article <20200615120806.gb1...@diablo.13thmonkey.org>, Reinoud Zandijk > <rein...@netbsd.org> 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