Re: General device properties API

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

> On Sep 12, 2021, at 1:58 AM, Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> 
> Why is this a requirement/problem?
> 
> The current mechanism still needs space in the kernel for the text of
> the name (the string "i2c-enumerate-devices").  Why refuse to expose
> that name to the linker so it can detect typos and namespace
> collisions?

Because is possible to construct situations where there are collisions that aren’t really errors, and avoiding them is complicated.

>> 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.
> 
> Only a .c file for the interface -- not the whole i2c subsystem --
> needs to be included.

So, let’s consider the following…

User builds modular kernel w/o i2c subsystem, so ACPI needs to include the interface binding object because it still have the i2c-enumerate-devices device call lurking inside of it.

User then loads the i2c subsystem.  But, does the i2c subsystem also have the interface binding object?  If it does, then you get a link error due to colliding symbols.  If not, then what happens if you try to load the i2c module on a system that does not have ACPI or OFW or whatever?  Do you get a link error this time because of an unresolved symbol?  Do you have to make the interface binding object **a separate module**?  And under what circumstances do you ensure it’s inclusion in a non-modular kernel?

Doing this with symbols is a mess.

-- thorpej