tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: General device properties API



> Date: Sun, 12 Sep 2021 08:17:15 -0700
> From: 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.

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?


Home | Main Index | Thread Index | Old Index