devctl(8): A device control utility

[John Baldwin]

On Monday, January 05, 2015 09:58:19 PM Hans Petter Selasky wrote:
> On 01/05/15 21:37, John Baldwin wrote:
> > On 1/5/15 3:13 PM, Hans Petter Selasky wrote:
> >> On 01/05/15 21:01, John Baldwin wrote:
> >>> The devctl(8) utility is then a thin wrapper around libdevctl (and
> >>> does not
> >>> yet have a manpage).
> >>> 
> >>> Do folks have any feedback?
> >> 
> >> Hi,
> >> 
> >> In the USB area attach and detach must be synchronized to the USB stack
> >> and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y reset" should
> >> be used to avoid races attaching and detaching drivers!
> > 
> > I think this points to one or more missing bus methods so that the bus
> > can hook into device_probe_and_attach() to reset a device as needed.
> > (e.g. if you had bus_probe_started / bus_probe_finished and possibly
> > similar methods for attach.  PCI could use a bus_attach_finished()
> > callback so that it could clean up any dangling resources and possibly
> > power down on a failed attach the way it does in bus_child_detached as
> > well).
> 
> Hi,
> 
> USB has its own threads to allocate/free devices. Another problem is how
> to atomically get a reference count across multiple layers like PCI and
> USB. It doesn't allow probe/attach when called from outside these threads.

That just means you need to use some locks. :)  Cardbus also uses an event
thread to handle auto-attach of devices when it detected a card change event,
but that doesn't prevent it from servicing an ioctl request.

> What happens if one instance of "devctl detach" detaches the USB PCI
> controller and another detaches a USB device, child of the USB PCI
> controller?

Right now new-bus is single-threaded, so one of those should wait on the 
other.  If it doesn't, that should be fixed in new-bus / the drivers.  It 
should not require extra hoops for the administrator.
 
> > Also, 'devctl detach' is a bit racy anyway as a subsequent kldload of
> > any driver on the bus will rescan the bus and try to attach any
> > unattached device.  'devctl disable' does not have this race, but it
> > currently matches 'hint.foo.0.disabled' and doesn't let you try an
> > alternate driver.  I consider attach/detach a bit more low-level while
> > enable/disable are probably more end-user friendly.  For the case of
> > letting a device rebid after loading a new driver, a new 'reprobe'
> > ioctl/command might be best rather than requiring an explicit
> > 'detach/attach'.
> 
> Is it a problem if devctl access is protected by a single SX lock and
> only can access PCI devices?

It is devctl, not pcictl.  It is not intended only for PCI devices (and in 
particular I tested it with ACPI-enumerated devices in a bhyve guest, not just 
PCI).  New-bus' locking in general is not robust and this might expose the 
need for refining that further (a global sx lock to replace the existing Giant 
locking wouldn't be a bad start), but that is orthogonal to the tool I think.

-- 
John Baldwin