From owner-freebsd-arch@FreeBSD.ORG Thu Jan 29 02:05:47 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 14E1D54D for ; Thu, 29 Jan 2015 02:05:47 +0000 (UTC) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEEFD86A for ; Thu, 29 Jan 2015 02:05:46 +0000 (UTC) Received: by mail-oi0-f46.google.com with SMTP id a141so22391425oig.5 for ; Wed, 28 Jan 2015 18:05:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=IWffjGuP27fWIJoEOQuxGMneQNOrzqdl38/+PySjUsE=; b=XbzTGXLEGN2dQFj9sFMuTZwvWkMVZ4VaH4/boYsKVTpyPOuTCQWMg0VPUVhkSi9ei6 PwMo1Ypwhw81IaCtWHGhPyyLhD6OcxMoLy1OThJPPsLEfFjdWkjPe9bcAuRaxs1Vz7T4 I5oq1YhAzLOxVVowt4DqIIT1I9S83rRKSSf1T1uGvuEsEdr0XVdzBxKfdkhy+OvV/+L0 zlG7YXVA/GZ3JsoaeR7rNWpFIFpIPi7jbg+DPe5RnH7K75ix4a/FIZtx5ofOnmfTvb6q dfh9Zu3Cm4g0RJpRMFTtyuuII9kzcF3IMs5fBtvA22s1Z05gmkvj9Zavt034wNzegnsb IjzQ== X-Gm-Message-State: ALoCoQn436wd8t86v/+bwqyNX4HV+GIAtEs13KO1tI7b/fFjjoHurmZ7PPbOF6JKI4ygZCtpwjEw X-Received: by 10.202.219.215 with SMTP id s206mr3833709oig.114.1422496749926; Wed, 28 Jan 2015 17:59:09 -0800 (PST) Received: from [172.16.173.216] ([12.196.110.43]) by mx.google.com with ESMTPSA id d198sm3122050oih.12.2015.01.28.17.59.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 Jan 2015 17:59:09 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: devctl(8): A device control utility From: Warner Losh In-Reply-To: <17592052.bbsckK6u9F@ralph.baldwin.cx> Date: Wed, 28 Jan 2015 18:59:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0EB7A69C-8623-49B8-96DC-AB7A84124D8A@bsdimp.com> References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54B44448.1090901@FreeBSD.org> <17592052.bbsckK6u9F@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.1993) 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: Thu, 29 Jan 2015 02:05:47 -0000 > On Jan 28, 2015, at 3:45 PM, John Baldwin wrote: >=20 > On Wednesday, January 14, 2015 04:56:18 PM Warner Losh wrote: >>> On Jan 12, 2015, at 3:01 PM, John Baldwin wrote: >>>=20 >>> On 1/12/15 12:01 PM, Warner Losh wrote: >>>>> On Jan 12, 2015, at 9:16 AM, John Baldwin wrote: >>>>>=20 >>>>> 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). >>>>>>>>>>=20 >>>>>>>>>> Do folks have any feedback? >>>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> 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! >>>>>>>>=20 >>>>>>>> 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). >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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. >>>>=20 >>>> When I was doing CardBus and PC Card I wished for similar things. = Then >>>> I realized I didn=E2=80=99t need them because as the bus author, I = know when >>>> these >>>> events happened and could take appropriate actions for the bus. I = didn=E2=80=99t >>>> 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... >>>=20 >>> I think the problem here is that devctl introduces events that = happen >>> without the bus's knowledge. >>=20 >> When we did the kludge sysctl power stuff for cardbus (which was = never >> committed), we sent a message to the bus to tell it to do the power = off and >> cope with whatever else was needed. There were times that it = couldn=E2=80=99t >> comply, iirc, so this =E2=80=98command=E2=80=99 allowed errors to be = returned for things >> that were forbidden / not allowed for some reason at the time rather = than >> getting a message that this thing happened and we had to mop up now. >=20 > devctl requests would always be ones that you can gracefully fail = (they are > administrative requests, not a surprise hardware removal). I think we = should > able to make that work just fine either by wrapping device_attach, = etc. in new > bus methods, or adding hooks into those as bus methods. To that end, = I'd like > to move forward with this current version in HEAD. At some point we = can=20 > decide which way we want to allow bus drivers to hook into these = requests. I=20 > don't think that will affect the API exposed to userland at all = however, only=20 > the in-kernel implementation. Yes. The only caveat in that would be if we wanted to have a force flag = passed down that the bus wouldn=E2=80=99t be allowed to reject. But that=E2=80=99= s a minor caveat, so I=E2=80=99m good moving forward with this model. Warner=