From owner-p4-projects@FreeBSD.ORG Fri Oct 3 15:52:55 2003 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 69D9516A4C0; Fri, 3 Oct 2003 15:52:55 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3613E16A4B3; Fri, 3 Oct 2003 15:52:55 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B787E44020; Fri, 3 Oct 2003 15:51:29 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p1/8.12.9) with ESMTP id h93MpDAD038686; Fri, 3 Oct 2003 16:51:14 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 03 Oct 2003 16:51:14 -0600 (MDT) Message-Id: <20031003.165114.08027459.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <20031003.000052.96921421.imp@bsdimp.com> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: jmallett@freebsd.org cc: hmp@nxad.com cc: perforce@freebsd.org cc: julian@elischer.org Subject: Re: PERFORCE change 38917 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2003 22:52:56 -0000 In message: John Baldwin writes: : : On 03-Oct-2003 M. Warner Losh wrote: : > In message: <20031002022135.GA26666@perrin.nxad.com> : > Hiten Pandya writes: : >: Does this also include PCI Hotplugging or is this going to be : >: a separate effort? : > : > Yes and no. : > : > We already have removable devices in the tree. CardBus, PC Card, USB : > and Firewire. Right now the drivers take liberties and chances and : > there are a number of ugly races that rear their ugly heads. This is : > an effort to clean that up and make things totally safe in all the : > cases that we can think of, and to document those areas where we : > can't. : > : > There's no specific plans on my part to implement the hot plug state : > transition and deal with it. People have raised their hands in the : > past to work on it, but so far no one has made significant progress in : > public view. : : BTW, I thought of a locking concern in attach routines this morning. : Basically, as soon as a driver does bus_setup_intr(), it needs to start : using any locks shared with its interrupt handler and the hardware : and driver state need to be able to handle having the handler invoked : when that function is called. The reason is that the device may be : attached to an interrupt line shared with another device and thus the : other device may generate an interrupt and call the new devices handler : before bus_setup_intr() even returns. Similarly, locking will be : needed after calls to disk_create(), if_attach(), etc. Yes. That's true. I'll keep it in mind. Warner