From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 20:57:33 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67B2C199; Mon, 5 Jan 2015 20:57:33 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AAAA2D87; Mon, 5 Jan 2015 20:57:33 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 3D19A1FE022; Mon, 5 Jan 2015 21:57:31 +0100 (CET) Message-ID: <54AAFAEB.2090505@selasky.org> Date: Mon, 05 Jan 2015 21:58:19 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Baldwin , arch@freebsd.org Subject: Re: devctl(8): A device control utility References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF07B.7030601@selasky.org> <54AAF60A.9070609@FreeBSD.org> In-Reply-To: <54AAF60A.9070609@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 20:57:33 -0000 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