untyped device calls (was: Re: General device properties API)

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Sep 20, 2021 at 09:03:12PM +0000, Taylor R Campbell wrote:
 > > 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.

I am confused by this whole discussion (which is why it's taken me
this long to reply) -- I see discussion of link sets and I see a patch
that seems to just add more goop around the strings (the one above),
but the problem with typing is very simple:

In the original device_call commit, instead of adding a vtable with
one "virtual function" (function pointer) per virtual call, for some
reason we got a single virtual function that looks up other virtual
functions by string name, and an API that uses void pointers to call
them.

That is, instead of

	devhandle->enumerate_children(dev, devhandle, callback, callback_arg)

(which one might dress up with a macro), we get, equally unwrapped:

	struct device_enumerate_children_args args;
	args.callback = callback;
	args.callback = callback_arg;
	call = devhandle->lookup_device_call(devhandle, "string", &handle2);
	call(dev, handle2, &args);

which is both much messier and much less safe, because the string is
completely uncheckable and might be typo'd, and the args are not
typechecked.

This creates a level of indirection, but what purpose does this level
of indirection serve? Looking at the implementation, it sure seems
like "none at all".

Why not just make each device call an entry in an ops table like every
other virtual call system we have?

-- 
David A. Holland
dholland%netbsd.org@localhost