> Date: Tue, 14 Sep 2021 06:39:11 -0700 > From: Jason Thorpe <thor...@me.com> > > > On Sep 12, 2021, at 9:14 AM, Taylor R Campbell > > <campbell+netbsd-tech-k...@mumble.net> wrote: > > > > Now the linker doesn't detect namespace collisions. So if two > > different subsystems in different modules take the same name you might > > silently get runtime memory corruption. > > I think we're at a point here where we disagree on whether or not > this will be an actual problem. I don't believe it will be an > actual problem and is therefore not worth the extra module > management complexity (which isn't free from a `space' perspective > because each module has to have code to handle loading and > unloading). We're in engineering trade-off land here, and I think > you're making the wrong one.
Namespace collisions are certainly an actual problem -- if they weren't, why would a linker bother to report them? This type of collision actually bites us in userland with ELF semantics -- because at runtime even accidental namespace collisions between shared libraries aren't an error, leading to bizarre ABI mismatch fallout when you get two versions of OpenSSL in the same program which usually manifests as a SIGSEGV with a stack trace that makes no sense. What is the `space' perspective? You're referring to the size of the module on disk, or of the struct modinfo and struct module in the kernel for a builtin module -- maybe a few dozen bytes to rule out an entire class of bugs? > In any case, here is a diff that adds the argument structure type > checking. I also added an awk program to generate the argument > structures and all of the call binding stuff automatically from an > interface description file. So, if someone wants to deal with the > additional module management complexity, they can change > gendevcalls.awk, re-gen the header files, and all of the call sites > will be updated automatically. > > https://www.netbsd.org/~thorpej/device-call-typing-diffs.txt This doesn't appear to do type-checking for formal parameters -- the functions still take void *. But, like I said before: I'd really like to establish what value this abstraction mechanism brings us in the first place -- still not clear to me.
