Date: Mon, 05 Jan 2015 21:58:19 +0100 From: Hans Petter Selasky <hps@selasky.org> To: John Baldwin <jhb@FreeBSD.org>, arch@freebsd.org Subject: Re: devctl(8): A device control utility Message-ID: <54AAFAEB.2090505@selasky.org> In-Reply-To: <54AAF60A.9070609@FreeBSD.org> References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF07B.7030601@selasky.org> <54AAF60A.9070609@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54AAFAEB.2090505>