From owner-p4-projects@FreeBSD.ORG Fri Oct 3 10:19:37 2003 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id E56B316A4C1; Fri, 3 Oct 2003 10:19:36 -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 BC76216A4B3 for ; Fri, 3 Oct 2003 10:19:36 -0700 (PDT) Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35A3743FF2 for ; Fri, 3 Oct 2003 10:19:35 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 23533 invoked from network); 3 Oct 2003 17:19:33 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 3 Oct 2003 17:19:33 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h93HHr6Y074606; Fri, 3 Oct 2003 13:17:53 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031003.000052.96921421.imp@bsdimp.com> Date: Fri, 03 Oct 2003 13:17:59 -0400 (EDT) From: John Baldwin To: "M. Warner Losh" X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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 17:19:37 -0000 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. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/