>What are the parameters?

The NetBSD folks changed things from my design, so I cannot answer
this exactly; but in any case, the rule is that there is no fixed
rule for the match function. :-)

In my setup, a match function receives the following parameters:

    struct device *parent
	A pointer to the base device structure for the parent at
	which an attempt is being made to match (or, depending on
	other kernel usage, probe) the child device.

    struct cfdata *cf
	The configuration data from ioconf.c that suggested that
	this might be a child of the given parent.

    void *aux
	Arbitrary data set up by the caller.

This function need not exist at all (and the pointer can be left
NULL) if the device probe is done indirectly, as on ISA busses,
Unibuses, and so forth.  In this case, the probe will necessarily
be performed via some other method, such as using the cd_aux field
of the `struct cfdriver' to point to an auxiliary data structure
specific to the ISA or Unibus or whatever.  The contents of such
a data structure are, obviously, left up to the code that runs the
devices which can support the child device in question.

On the sun4c and sun4m SPARCs, none of the busses require indirect
configuration -- the FORTH PROM knows about all the top-level
devices, and the Sbus, obio, or iommu node has all the information
about any attached devices.  Here, then, the xxmatch() function
will get, as its `void *aux', a pointer to a `struct romaux'.
(Of course, once you reach the SCSI bus, everything changes again;
this applies only to top-level and obio/sbus/iommu devices.)
The romaux gives the name of the device (minus the leading manufacturer
part if any), addresses, interrupt data, sbus slot, etc.

On the sun4, the match function should not be used; instead, the
obio driver will use the cd_aux field to locate a `struct s4p'
giving details on how to probe for the device's existence (most
cases can then be handled with no assistance from the device).
If the device is not sun4-capable (e.g., the sun4c/sun4m-only
clock), this aux pointer may be left NULL.

If the match function exists, its job is to determine how well
the given child device fits in as suggested by the `cf' and `aux'
data.  If the given child is definitely *not* present, it can
return 0; if it is, any nonzero value will suffice, and the higher
the value, the `tighter' the match -- so you can have a special
version of a driver (or special entry points) to work around broken
hardware without affecting the main body of the regular driver.

The attach function is much better defined.  It receives:

    struct device *parent
	The parent that was ultimately used.

    struct device *self
	The base device structure allocated for the driver (actual
	size self->df_cfdata->cf_driver->cd_devsize; this must
	be >= sizeof(struct device)).

    void *aux
	Auxiliary data provided by the parent.

Again, on the sparcs, the `aux' will be a pointer to a `struct romaux'.

Chris