From owner-freebsd-hackers@FreeBSD.ORG Sun May 21 06:10:13 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 1939516A434 for ; Sun, 21 May 2006 06:10:13 +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 933F343D46 for ; Sun, 21 May 2006 06:10:12 +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 k4L67TGo039311; Sun, 21 May 2006 00:07:29 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 21 May 2006 00:07:29 -0600 (MDT) Message-Id: <20060521.000729.41671970.imp@bsdimp.com> To: avalonwallace@gmail.com From: Warner Losh In-Reply-To: <87ab37ab0605201942o3e27c46w2ac57261e02a2890@mail.gmail.com> References: <87ab37ab0605192239n73b7fcdbtbdd5dbd3f1099fc3@mail.gmail.com> <20060520.013546.104050983.imp@bsdimp.com> <87ab37ab0605201942o3e27c46w2ac57261e02a2890@mail.gmail.com> X-Mailer: Mew version 3.3 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, 21 May 2006 06:10:13 -0000 > still a question about newbus 's BUS interface : > usage of DEVICE_IDENTIFY AND BUS_ADD_CHILD > I know these bus interface func r called accessor functions ,that call > the appropriate function by checking the parameter.just like the > polymorphism technic in OOP . that's really a magic :) > my first QUESTION is what if the calling device do not realize the > corresponding interface ? taking bus_add_child interface as example. > only a few device-drivers have implement it ,but more r called for it > .what will happen when BUS_ADD_CHILD(device_t bus, int order, const > char *name, int unit) 's bus do not implement it ? The BUS_ADD_CHILD interface is called by the bus. Children drivers don't need to know/care about it. They aren't always needed, however. You'll likely find that only busses that are not self-enumerating have these registered. This is so that when the identiy routines are called to enumerate the children otherwise unknown to the parent bus, the parent bus gets notification of the addition of these new chilren. > my second is :a driver's DEVICE_IDENTIFY always call its device 's > parent's BUS_ADD_CHILD ,what is the semantic of them:) > thank u nope. It may be called once per bus instance per driver, if the bus is not self-identifying. If the bus is self-idntiying, chances are that it will not be called. pci never calls its children drivers' identify routine because it already knows all the children on the bus and doesn't need the leaf drivers to go find instances of themselves. the isa bus driver, on the other hand, does call the identify routine so that pre-plug and play standard device enumeration can happen. Warner > the drivers who have registered the bus_add_child (not too many) > Acpi.c (dev\acpica): DEVMETHOD(bus_add_child, acpi_add_child), > Atkbdc_isa.c (isa): DEVMETHOD(bus_add_child, atkbdc_add_child), > Canbus.c (pc98\pc98): DEVMETHOD(bus_add_child, canbus_add_child), > Firewire.c (dev\firewire): DEVMETHOD(bus_add_child, firewire_add_child), > Fwohci_pci.c (dev\firewire): DEVMETHOD(bus_add_child, fwohci_pci_add_child), > Iicbus.c (dev\iicbus): DEVMETHOD(bus_add_child, iicbus_add_child), > Isa_common.c (isa): DEVMETHOD(bus_add_child, isa_add_child), > Legacy.c (amd64\amd64): DEVMETHOD(bus_add_child, legacy_add_child), > Legacy.c (i386\i386): DEVMETHOD(bus_add_child, legacy_add_child), > Nexus.c (amd64\amd64): DEVMETHOD(bus_add_child, nexus_add_child), > Nexus.c (i386\i386): DEVMETHOD(bus_add_child, nexus_add_child), > Nexus.c (ia64\ia64): DEVMETHOD(bus_add_child, nexus_add_child), > Ppbconf.c (dev\ppbus): DEVMETHOD(bus_add_child, ppbus_add_child), > Smbus.c (dev\smbus): DEVMETHOD(bus_add_child, smbus_add_child), > > > 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 > > > > > > > > > > > > > -- > > > we who r about to die,salute u! > > > > > > > > > > > -- > we who r about to die,salute u! > >