devctl(8): A device control utility

Hans Petter Selasky hps at selasky.org
Mon Jan 5 20:57:33 UTC 2015


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.

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?

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

--HPS



More information about the freebsd-arch mailing list