Re: General device properties API

[Jason Thorpe <thorpej%me.com@localhost>]

> On Sep 11, 2021, at 4:29 PM, Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> 
> Here's another sketch that is much more flexible and general.
> Adapting it to link sets should be easy; the main point is that the
> only untyped parts going through void * are limited to the definition
> site of a generic operation; everything else is fully typed.

Looks quite verbose, but I’ll study it some more.  The sketch seems somewhat incomplete, so I’m not really getting how you’re suggesting it should be used.

> That said, I haven't processed all of the abstractions you're
> introducing or the class of related problem domains they intend to
> solve.  So I'm not convinced yet that the additional flexibility is
> necessary or useful.  But at least it is guaranteed to detect typos
> and type errors.

Another thing I’m trying to comprehend here is just what kind of typos and type errors you think will be prevented.  If the name of the “args” structure is wrong, it will either fail to compile (because the args structure name used doesn’t exist, so accessing fields will fail to compile), or the error will be glaringly obvious because you used “spi_enumerate_devices_args” when you should have use “i2c_enumerate_devices_args” and the member names are different.

I.e. I’m having a lot of trouble assessing the value of a more complicated solution like your proposed vtable, when there doesn’t really seem to be an actual *problem*.

> If this doesn't meet the attributes you laid out earlier either, I
> would appreciate it if you could identify which ones I missed --
> there's too much going on here to fit in my head at once.

Ok, once again:

==> Allows multiple implementations of a method to exist and be used within the same system (e.g. ACPI and FDT/OFW co-existing).

==> Does not require referencing a symbol that would cause a link failure if a method is not available on some platform scheme.

==> Allows for platforms that don’t have a platform device tree to still provide those methods so as to participate in the higher-level mechanisms that utilize them.

==> Does not require modifying general-purpose code in order to implement special-purpose methods (i.e. adding a method for PCI should only require modifying code in sys/dev/pci + the OFW / ACPI / whatever code that’s providing the service to PCI).

==> Does not needlessly make it more difficult for NetBSD to have a stable kernel ABI in the future.

On the surface, your vtable sketch seems to satisfy all of these, but it seems awfully verbose.

…although I should have added the following to the original list:

==> Allows for a subclassing model whereby individual methods can be overridden on a per-devhandle basis.  This is critical to the i2c changes I just posted to tech-kern@.

But one problem your vtable sketch has is that is requires referencing a symbol (i2c_enumerate_devices_generic, i2c_enumerate_devices_typecheck, and i2c_enumerate_devices).  I suppose I should adjust my #2 property above… in addition to not causing a link failure if e.g. ACPI doesn’t provide some method, nor should there be a link failure if ACPI provides enumeration support for I2C but the I2C module isn’t currently loaded.

As such, it seems like it’s not a better solution than the one I’ve already implemented.

-- thorpej