# Matthias Drochner 2006-11-01:
> 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".

Things are somewhat complicated by the way our autoconf(9) currently
works. Among other things, "device_t" == "device _and_ driver". I think
this should change, but won't have time to work on it anytime soon.

So, thinking about this (and the rest of your mail), it seems reasonable
to limit devmon to cover case (b) for now. The API can just announce
attach/detach of driver instances, and probably provide a set of ioctls
to query device (as in "the device rtk0 driver instance is attached to")
for additional information (this would be needed at least for hierarchical
matches the original implementation supported, and I think it was a neat
feature).

After autoconf(9) gets some treatment, handling case (a) would just
mean adding a new event type ("device", as opposed to "driver").

(Other then my point of view being strongly devmon-centric, I think
I agree with what you say on how things should work.)

> 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.

I'm not sure what you mean by (3), can you give an example?

	-- Jachym