From owner-freebsd-arch@FreeBSD.ORG Mon Jan 12 22:01:48 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 40DADB72 for ; Mon, 12 Jan 2015 22:01:48 +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 16DD93ED for ; Mon, 12 Jan 2015 22:01:48 +0000 (UTC) Received: from new-host-4.home (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C391EB915; Mon, 12 Jan 2015 17:01:45 -0500 (EST) Message-ID: <54B44448.1090901@FreeBSD.org> Date: Mon, 12 Jan 2015 17:01:44 -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: Warner Losh Subject: Re: devctl(8): A device control utility References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF60A.9070609@FreeBSD.org> <54AAFAEB.2090505@selasky.org> <6155572.yV5dxPJznD@ralph.baldwin.cx> <54B3F349.9050703@FreeBSD.org> <11219A27-4C5B-4429-8847-3E54F9C4CD1E@bsdimp.com> In-Reply-To: <11219A27-4C5B-4429-8847-3E54F9C4CD1E@bsdimp.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 12 Jan 2015 17:01:45 -0500 (EST) Cc: Hans Petter Selasky , 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, 12 Jan 2015 22:01:48 -0000 On 1/12/15 12:01 PM, Warner Losh wrote: > >> On Jan 12, 2015, at 9:16 AM, John Baldwin wrote: >> >> On 1/5/15 4:18 PM, John Baldwin wrote: >>> 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. >> >> Another option btw would be to add bus methods that wrap probe and >> attach (rather than pre and post event hooks). I wish bus_add_child() >> were done this way such that device_add_child_ordered() were renamed to >> bus_generic_add_child() (and was the default add_child method) and that >> device_add_child_ordered() called 'BUS_ADD_CHILD()' so that >> 'device_add_child()' was the proper public API (instead of exposing >> BUS_ADD_CHILD()). Similarly, I think that 'device_attach()' and >> 'device_probe_and_attach()' should be the public API and that one way or >> another we should add hooks to allow bus drivers to modify their >> behavior if needed. However, they should be fine for devctl ioctls to >> invoke as well as other kernel bits. > > When I was doing CardBus and PC Card I wished for similar things. Then > I realized I didn’t need them because as the bus author, I know when these > events happened and could take appropriate actions for the bus. I didn’t have > that atomic access issues though, since as the bus author I also controlled how > and when mutexes were taken out and when I allowed access to the bus. I > only used mutexes in CardBus and PC Card because most of the sleeps were > short, but other ways to do locking are quite possible... I think the problem here is that devctl introduces events that happen without the bus's knowledge. -- John Baldwin