From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 20:37:34 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C0865E4 for ; Mon, 5 Jan 2015 20:37:34 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 763BC28C3 for ; Mon, 5 Jan 2015 20:37:34 +0000 (UTC) Received: from new-host-2.home (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6F878B913; Mon, 5 Jan 2015 15:37:32 -0500 (EST) Message-ID: <54AAF60A.9070609@FreeBSD.org> Date: Mon, 05 Jan 2015 15:37:30 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Hans Petter Selasky , arch@freebsd.org Subject: Re: devctl(8): A device control utility References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF07B.7030601@selasky.org> In-Reply-To: <54AAF07B.7030601@selasky.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 05 Jan 2015 15:37:32 -0500 (EST) 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:37:34 -0000 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). 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'. -- John Baldwin