Re: Inter-driver #if dependencies

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Tue, 19 May 2015 06:57:44 +0800 (PHT)
   From: Paul Goyette <paul%vps1.whooppee.com@localhost>

   On Mon, 18 May 2015, Masao Uebayashi wrote:

   > How about:
   >
   > - making pcppi(4) provide the new pcppibus(4), and
   > - making attimer(4) and pckbd(4) attach at pcppibus(4)

   A couple of issues with this approach:

           * pckbd already attaches at an unrelated parent, pckbc
           * attimer can attach currently at acpi, as well as at isa

   The real problem here is that these other drivers, whether they're 
   children of pcppi or of something else, are optional.  And their very 
   presence, whether or not any instance is actually configured, (and 
   without regard to where they are attached) changes the behavior of 
   pcppi.

Can you explain how the devices are actually related, both in the
hardware and in the kernel representations of it, irrespective of how
it is currently manifested in autoconf?

Sometimes there is a non-tree relation between two devices in a piece
of physical hardware which both hang off a generic bus that ought not
to have device-specific hacks to make the two talk.  E.g., the HD
audio and graphics devices on current Intel PCI buses exhibit this.

But I'm not sure a generic autoconf mechanism is warranted for such
glue.  Better to identify working solutions for specific cases and
then generalize, rather than start with a super-generic mechanism
before it has been demonstrated to work well in any specific case.