> Date: Sun, 12 Sep 2021 08:17:15 -0700 > From: Jason Thorpe <thor...@me.com> > > > On Sep 12, 2021, at 1:58 AM, Taylor R Campbell > > <campbell+netbsd-tech-k...@mumble.net> 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.
Can you expand on this -- what's a realistic situation where there's a legitimate collision (as in, using a defined symbol would be rejected by the linker) but it's not an error (because somehow the two separate definitions are actually intended to have the same semantics and yet are not the same symbol)? > 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? What's wrong with a separate module? Module dependencies get resolved automatically, no extra work for users. You ensure its inclusion in a nonmodular kernel (or in acpi.kmod) under the same conditions you currently have ACPI_DEVICE_REGISTER_CALL(i2c_enumerate_devices), which looks to me like it's unconditional now?