I've not read most of this discussion (skimmed), and don't really have
time to pursue it in depth, but:


> So does your statement imply I should not define my own attach args structure
> and config(8) will do it for me? Or should I copy the necessary information
> to my homemade attach args structure before passing it to config_found? How
> would I get to the config file values at that point?

locators are created and provided by config, based on information
provided in the configuration file, and that information only.
locators should be treated as 'const' by all parts of the kernel.

attach_args structures, passed as the void *aux to match and attach
routines, should contain location information determined at run-time.
They are initially filled in by bus drivers with location information
and any other appropriate data determined by the bus.

In the case of direct-config devices (which are configured with
config_found()), the purpose of the match function is to determine
whether the device driver (with those locators) matches the device
described by the attach args?  The attach args should be considered
constant for direct-config devices.  They should be compared with the
locators (perhaps by a bus submatch function), and the device they
describe, should be examined by the match function for a successful
match.

In the case of indirect-config devices (configured with
config_search() or -- if broken bus -- config_scan()), the purpose of
the match function is to determine whether the device driver can find
one of its devices at the location specified by the attach args.
Depending on the contents of the attach args, the locators may be
unused.  (Often, the contents of the attach args will be directly
derived from the locators.)  The attach_args should be modified by the
driver, if the driver can supply any additional information (e.g. I/O
space size, etc.).


You said you're using direct config, right?  You probably should be
using some sort of locator to allow users to nail down device units to
particular locations (even if they're only logical locations),
e.g. ISDN channels.


> P.S.: The usual question at this point: any pointers to documentation of 
> our current auto config system?

Chris Torek wrote a paper about 4.4BSD "new config", but never
finished that paper.  That paper comes close to describing the
autoconfiguration system used in NetBSD, but doesn't cover a few cases
(most notably __BROKEN_INDIRECT_CONFIG, which was added by us and is
in the process of being removed by us, and the cfdriver/cfattach
split, which was added by us and is hopefully here to stay 8-).



cgd