Re: General device properties API

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Tue, 14 Sep 2021 06:39:11 -0700
> From: Jason Thorpe <thorpej%me.com@localhost>
> 
> > On Sep 12, 2021, at 9:14 AM, Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> 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.