Re: Inter-driver #if dependencies

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, May 18, 2015 at 06:40:35AM +0800, Paul Goyette wrote:
 > My crusade for modularity has arrived at the pcppi(4) driver, and I've
 > discovered that there are a number of places in the code where a #if is
 > used to determine whether or not some _other_ driver is available to
 > provide certain routines.  For pcppi(4), these dependencies are for the
 > attimer(4) and pckbd(4) drivers.  (While I haven't yet gone searching, I'd
 > be willing to wager that there are other similar examples in other
 > drivers.)
 > 
 > These #if constructs make it very difficult to modularize these drivers.
 > 
 > I'd like to propose the following new kernel mechanism that will allow us
 > to remove these #if dependencies.
 > 
 > 1. Extend the struct cfattach to have an additional member, and create
 >    a new CFATTACH_DECL4_NEW macro to initialize it (and updates to the
 >    existing CFATTACH_* family to default the value to NULL).
 > 
 > 	int	(*ca_callback)(device_t, int, void *);
 > 
 >    (This will require a kernel version bump.)
 > 
 > 2. In kern/subr_device.c (or kern/subr_autoconfig) add a new routine
 >    to call the callback routines for a driver until something handles
 >    the request.  Note that the caller provides a device_t to identify
 >    itself to the callback routine.

Ugh please no.

The idea of attacing driver A to bus B is that B provides a set of
function pointers for A to call to do bus operations... and A also
provides a set of function pointers for B to call as callbacks, like
interrupt handlers.

If you need more such functions, extend the interface between the A
and B you're dealing with; don't wedge stuff into the generic device
scheme as a shortcut to avoid redesigning that interface.

-- 
David A. Holland
dholland%netbsd.org@localhost