Subject: Re: Pluged : USBd for NetBSD ?
To: None <>
From: Warner Losh <>
List: tech-kern
Date: 01/22/2005 22:27:00
From: Jachym Holecek <>
Subject: Re: Pluged : USBd for NetBSD ?
Date: Sun, 23 Jan 2005 06:18:23 +0100

> > : > Something like usbd is doubtlessly needed.  It would be
> > : > nice if it could be common for all hot pluggable devices.
> > : 
> > : The recently-introduced /dev/drvctl seems to be a good place to
> > : communicate driver attach/detach messages from the kernel to
> > : userland. We have attach and detach sufficently centralized that it
> > : shouldn't be hard to cause a message to be generated for a listener
> > : there.
> > 
> > For FreeBSD, I was able to add about 200 lines of code to the kernel
> > to newbus' centeralized location for each device's attach, detach and
> > failure to probe.  I then wrote devd to cope with the events from the
> > kernel.  At first, I tried to allow devd to 'vote' on what to do for
> > unknown devices, but abadoned that idea in favor of having it just
> > load a new kernel driver, which would then claim the device.
> > 
> > NetBSD's centralized attach/detach stuff should prove sufficient.
> 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.  Actually, they care the /dev/foo0 arrived, which can be a
different creature than a device known to the config system as foo0. 

> 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...
> 	Regards,
> 		-- Jachym Holecek
> [*] Seems better then having a per-source daemon, each rolling its own
>     config syntax.

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

I didn't relish the thought of having multiple daemons either, and
FreeBSD's device configuration system was flexible enough to get me
the last bit that wasn't already there.