From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 4 07:29:34 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 8C7BF16A473 for ; Sun, 4 Jun 2006 07:29:34 +0000 (UTC) (envelope-from fierykylin@gmail.com) Received: from wx-out-0102.google.com (wx-out-0102.google.com [66.249.82.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA1C543D4C for ; Sun, 4 Jun 2006 07:29:33 +0000 (GMT) (envelope-from fierykylin@gmail.com) Received: by wx-out-0102.google.com with SMTP id i31so568897wxd for ; Sun, 04 Jun 2006 00:29:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=QqrsppV4zjHwPOzL0h2Nsb5Gi1Y7jmoBa96ipPIOYy88MPrLm2Vsg/Pw9HevqDyVk20DAGBvLMuGKIpxQRphKq5icF7JG3RsBdnWDqUQ7AD3U6jLJyejiyJfcQRHaKj2o6/sPwS5Hi0xh0Zkmb9htaTW6bIEYKkCqUiDVatxRXM= Received: by 10.70.8.2 with SMTP id 2mr1456467wxh; Sun, 04 Jun 2006 00:29:31 -0700 (PDT) Received: by 10.70.43.11 with HTTP; Sun, 4 Jun 2006 00:29:31 -0700 (PDT) Message-ID: <87ab37ab0606040029u67edc35ende0b34e39e80bd37@mail.gmail.com> Date: Sun, 4 Jun 2006 15:29:31 +0800 From: "william wallace" Sender: fierykylin@gmail.com To: "Warner Losh" In-Reply-To: <20060520.013546.104050983.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <87ab37ab0605192015h363ef74aw23dcc2d97721dea9@mail.gmail.com> <20060519.232002.71106210.imp@bsdimp.com> <87ab37ab0605192239n73b7fcdbtbdd5dbd3f1099fc3@mail.gmail.com> <20060520.013546.104050983.imp@bsdimp.com> X-Google-Sender-Auth: 916a99c1dc7c7660 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 07:29:34 -0000 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? -- we who r about to die,salute u!