> On Sep 12, 2021, at 1:58 AM, Taylor R Campbell > <[email protected]> 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
