From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 4 10:37:38 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E92516A474 for ; Sun, 4 Jun 2006 10:37:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6A2343D48 for ; Sun, 4 Jun 2006 10:37:37 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [IPv6:::1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k54AbHMB035954; Sun, 4 Jun 2006 04:37:17 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 04 Jun 2006 04:37:25 -0600 (MDT) Message-Id: <20060604.043725.778152499.imp@bsdimp.com> To: avalonwallace@gmail.com From: "M. Warner Losh" In-Reply-To: <87ab37ab0606040029u67edc35ende0b34e39e80bd37@mail.gmail.com> References: <87ab37ab0605192239n73b7fcdbtbdd5dbd3f1099fc3@mail.gmail.com> <20060520.013546.104050983.imp@bsdimp.com> <87ab37ab0606040029u67edc35ende0b34e39e80bd37@mail.gmail.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: misc questions about the device&driver arch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2006 10:37:39 -0000 In message: <87ab37ab0606040029u67edc35ende0b34e39e80bd37@mail.gmail.com> "william wallace" writes: : On 5/20/06, Warner Losh wrote: : > From: "william wallace" : > Subject: Re: misc questions about the device&driver arch : > Date: Sat, 20 May 2006 13:39:08 +0800 : > : > > comparing the method array of pci_pci and cardbusbridge: : > > what losts in pci bridge but exist in cardbusbridge: : > > 1 card interface : > > 2 power interface : > > 3 some functions : : > > 3ain bus interface : > > (bus_driver_added, cbb_driver_added), : > > (bus_child_detached, cbb_child_detached), : > > (bus_child_present, cbb_child_present), : > > 3b in device interface : > > (device_detach, cbb_detach), : > > what exists in pci bridge but losts in cardbusbridge: : > > (pcib_route_interrupt, pcib_route_interrupt), : > > : > > not only that ,functions r very different eventhough they realize the : > > same interface function template : > > wooo，so long to go to hotplug pci : > : > Yes. The hardest part would be to create a pci hot swap bridge : > driver. The interface for them tend to be underdocumented. : > : > The bus_child_present is important for detaching. : > : > Also, I think that we may need to start implementing a quiess method : > to tell the drivers they are about to be removed. For hot plug PCI, : > the model is that you quess the driver, the os tells you somehow it is : > safe, and then you remove the card. The details vary (some system are : > all in software, while others have a complicated interlock and LEDs), : > but they are similar. Cardbus is harder in some ways because cards : > leave unannounced (in fact, there's not a good way to announce a card : > leaving, but there should be). : > : > Warner : > : > > On 5/20/06, Warner Losh wrote: : > > : > > > Busses create devices to represent hardware in the system. The bus : > > > then causes these devices to be probed and attached. This latter : > > > usage is for those cases. As drivers are loaded these devices are : > > > offered to the new (and old) drivers in the system. : > > > : > > > FreeBSD inherently dynamic in its device system. The hardest part of : > > > adding hotplug support is programming the bridge. Adding new devices : > > > to the tree is easy, but knowing when to add them is hard since you : > > > have to write a bridge driver... : > > > : > > > Warner : Prior to removing a card from the system, two things must occur: : : The device's driver must cease accessing the card. : : The card must cease generation transaction and interrupts. : : How this is accomplished is OS-specific, but the following must take place: : : The OS must stop issuing new requests to the device's driver or must : instruct the driver to stop accepting new requests. : : The driver must terminate or complete all outstanding requests. : : The card must be disabled from generating interrupts or transactions. : : When the OS commands the driver to quiesce itself and its device, the : OS must not expect the device to remain in the system (in other words, : it could be removed and not replaced with a similar card). : : How to design and implement quiescing in freebsd? device_quiesce? I have it in a p4 tree right now. Specifically, it hooks up to the MOD_UNLOAD with a QUIESCE flag. The driver's device_quiesce routine gets called, the driver sleeps there until it knows that it is good, then returns to the caller. Then the driver's detach routine can be called. Warner