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