On Mon, Jun 15, 2020 at 10:56:04PM +0000, David Holland wrote: > 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.
OK, this could be improved if we had the IOR/IOW/IORW flags for each syscall pointer arg available in the description (like all interface description languages have). > 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. Since we have many architectures that just crash on such mistakes, I don't think there is a big gain. But generated code is good anyway (I'm a lazy programer). > > > - 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. Ok, so you want to read the syscall specification for NetBSD, the one for Ultrix (both in the new input format), where the Ultrix one has addititional references into the NetBSD one for syscalls that map nearly 1:1, and then auto-generate the conversion code. This is a step further than for the netbsd32 (or in general: same syscall, different ABI) compat. > > 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. Yes, sure. But does it need to be the same tool? The output format will be quite different. Same input specs: sure. > > 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. OK, but again they need totaly different output, so might just be a different tool (and also an upstream problem). We probably would have to provide some tool to convert the shiny new syscall definition format into whatever the upstream tool accepts as input. > > 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. :-/ IMO you did jump over quite a few steps and assume some special handling/ process model in your imaginary solution already, and I am not sure everyone understands your model, the design decisions leading to it and agrees with them. Martin
