thorpej@shagadelic.org said:
> > I think with current state of autoconf(9) the code is fairly OK. We'd
> > need to move relevant members of <foo>_attach_args to locators and  
> > maybe
> > replace cf_loc with property lists to get somewhat better. 
> > [...]
> We now have plists, and should use them

I'd say things are more complex than just converting attach args.
If we start with a new interface here, we should try to get the
structure right and keep as much abstraction as possible.

There are (at least) two different interactions with userland we
need to consider:
a) A device is plugged in, the bus is either able to detect this
   or a "rescan"-like ioctl was invoked, but there is no applicable
   driver present in the kernel. This is to demand-load a driver
   module. Less interesting for general userland programs, in
   particular "hal".
b) A new driver instance was attached, either through (a), or just
   because a new driver was loaded. This is what is interesting for
   userland programs, in particular "hal".

The "attach args" (generalized) consist of:
1) Some vendor/device ID (and class/revision/whatever), telling the
   type of the device, but not an individual instance.
2) "Locators", telling the address on the parent bus.
3) Something identifying a device instance, sometimes called "Vital
   Product Data", should be bus independant.
4) Tag/handle and other kernel-internal stuff.

The (a) case is of less immediate interest; what needs to be done
here is to formalize the "device match" stuff in a way that kernel
drivers and a userland program trying to match a driver do a device
ID use the same database. plists are an obvious choice here; this
means that the kernel must use a plistified version of eg "pcidevs"
and "usbdevs".
This is a lot of work.

What's more important for user programs is to get notified about
instances of devices when they exist or appear. At this point we
are assuming that the driver has been found and attached.
In theory, the user program shouldn't care about bus specific
attachment stuff. (In particular, given eg the various ways a
compactflash card can be seen, via IDE or USB, it shouldn't matter.)
So if possible not more than the NetBSD device name, a generic
type and "Vital Product Data", if present, should be transferred here.

best regards
Matthias