> > Yes, kernel changes needed for that are trivial. Event daemon based solely
> > on autoconf(9) isn't strong enough though -- additional interfaces (such as
> > /dev/usb) may provide more information about the device, that may help you
> > distinguish between different usb flash disks for instance and mount them
> > at different locations. I think that would be what users expect.
> 
> Agreed.  That's why devd uses that information.  However, experience
> has shown that most users don't care at all about location, plug and
> play information, etc.  They just care that device foo0 arrived at the
> scene.

That's interesting to know.

>        Actually, they care the /dev/foo0 arrived, which can be a
> different creature than a device known to the config system as foo0. 

Yeah, that's exactly the case of a multiport ethernet controller I worked
with a week ago or so, where foo0 maps to interfaces foo0e[0-3].

> > I'm currently playing around with a daemon that listens to several device
> > event sources [*] and takes actions according to a config file, much like
> > usbd does -- just a bit more general. [This seems more reasonable approach
> > then trying to invent some Kernel Unified Device Notification Theory, which
> > I was thinking about for a few minutes.] Not that I got something terribly
> > useful yet...
> 
> You may seriously want to take a look at what FreeBSD's devd does.
> One of the things that newbus has is the concept of a bus specific
> location, as well as a bus specific plug and play information.  When
> the events are played up to devd, all that information is there.  When
> I did devd, I didn't have to change any drivers or busses to get basic
> functionality (and only had to change the bus drivers to get the bus
> specific location and plug and play information).

Sounds nice, time to checkout FreeBSD sources. Thanks for the pointer.

	Regards,
		-- Jachym Holecek