From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 21:34:09 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 68C7CBED for ; Mon, 5 Jan 2015 21:34:09 +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 40577643DE for ; Mon, 5 Jan 2015 21:34:09 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 38297B926; Mon, 5 Jan 2015 16:34:07 -0500 (EST) From: John Baldwin To: Hans Petter Selasky Subject: Re: devctl(8): A device control utility Date: Mon, 05 Jan 2015 16:18:21 -0500 Message-ID: <6155572.yV5dxPJznD@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <54AAFAEB.2090505@selasky.org> References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF60A.9070609@FreeBSD.org> <54AAFAEB.2090505@selasky.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 05 Jan 2015 16:34:07 -0500 (EST) Cc: arch@freebsd.org 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 21:34:09 -0000 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