From owner-freebsd-arch@FreeBSD.ORG Tue Jan 27 21:04:42 2015 Return-Path: Delivered-To: freebsd-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 628AC69E for ; Tue, 27 Jan 2015 21:04:42 +0000 (UTC) Received: from maila-ca.linkedin.com (maila-ca.linkedin.com [108.174.6.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.linkedin.com", Issuer "DigiCert Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23C89A94 for ; Tue, 27 Jan 2015 21:04:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; s=proddkim1024; t=1422392674; bh=3ulVqcUdyerSmzHj6ojQK9jNPdakT76KC/mEXbS9IaI=; h=From:Subject:MIME-Version:Content-Type:To:Date:X-LinkedIn-Class: X-LinkedIn-Template:X-LinkedIn-fbl; b=fieBC3if4b/VwU7y2Sy5ZdZ4yyuA2sQJ/umDGsDJ42YgNftw2iZNb63k5TJsOKG7C NvH2lP56GY9X0j2Zwn1oZwQuuT8R+6xUNqPlQkJL3XMGKy87LPKUQDkFEHf2Wutctm Rzn0SrNYPDRSbO0ZH3F4pHzE6Rsw+wFr0MixipbI= From: LinkedIn Security Message-ID: <1748019091.10903717.1422392674491.JavaMail.app@lva1-app8991.prod> Subject: Sairam, your password was successfully reset MIME-Version: 1.0 To: Sairam Chengala Date: Tue, 27 Jan 2015 21:04:34 +0000 (UTC) X-LinkedIn-Class: ACCT-ADMIN X-LinkedIn-Template: security_reset_password_notification X-LinkedIn-fbl: s-2nymzewhsrn5s9qoleiprkdpiizoqlh9ibeeirur6llv0searwt14to0 X-LinkedIn-Id: i9hmy-i5frvfnl-4h Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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: Tue, 27 Jan 2015 21:04:42 -0000 Hi Sairam, You've successfully changed your LinkedIn password. Thanks for using LinkedIn! The LinkedIn Team When and where this happened: Date:January 27, 2015 4:04 PM Browser:Chrome Operating System:OS X IP Address:96.240.100.124 Approximate Location:Hoboken, New Jersey, United States Didn't do this? Be sure to change your password right away: https://www.lin= kedin.com/e/v2?e=3Di9hmy-i5frvfnl-4h&a=3Duas-request-password-reset&midToke= n=3DAQFN2Z6JzeYPdA&ek=3Dsecurity_reset_password_notification From owner-freebsd-arch@FreeBSD.ORG Wed Jan 28 22:46:03 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 BEF6428A for ; Wed, 28 Jan 2015 22:46:03 +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 7BDB2DEC for ; Wed, 28 Jan 2015 22:46:03 +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 694FDB926; Wed, 28 Jan 2015 17:46:01 -0500 (EST) From: John Baldwin To: Warner Losh Subject: Re: devctl(8): A device control utility Date: Wed, 28 Jan 2015 17:45:25 -0500 Message-ID: <17592052.bbsckK6u9F@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54B44448.1090901@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 28 Jan 2015 17:46:01 -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: Wed, 28 Jan 2015 22:46:03 -0000 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 wrot= e: > >>>>> 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 libdevct= l (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 rese= t" > >>>>>>> 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 n= eeded. > >>>>>> (e.g. if you had bus_probe_started / bus_probe_finished and po= ssibly > >>>>>> similar methods for attach. PCI could use a bus_attach_finish= ed() > >>>>>> 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_det= ached > >>>>>> as > >>>>>> well). > >>>>>=20 > >>>>> Hi, > >>>>>=20 > >>>>> USB has its own threads to allocate/free devices. Another probl= em 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 the= se > >>>>> threads. > >>>>=20 > >>>> That just means you need to use some locks. :) Cardbus also use= s 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 reque= st. > >>>=20 > >>> Another option btw would be to add bus methods that wrap probe an= d > >>> attach (rather than pre and post event hooks). I wish bus_add_ch= ild() > >>> were done this way such that device_add_child_ordered() were rena= med to > >>> bus_generic_add_child() (and was the default add_child method) an= d that > >>> device_add_child_ordered() called 'BUS_ADD_CHILD()' so that > >>> 'device_add_child()' was the proper public API (instead of exposi= ng > >>> 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 ioct= ls 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 a= lso > >> 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 mos= t 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 happ= en > > without the bus's knowledge. >=20 > When we did the kludge sysctl power stuff for cardbus (which was neve= r > committed), we sent a message to the bus to tell it to do the power o= ff 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. 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 ca= n=20 decide which way we want to allow bus drivers to hook into these reques= ts. I=20 don't think that will affect the API exposed to userland at all however= , only=20 the in-kernel implementation. --=20 John Baldwin