Date: Sun, 21 May 2006 10:42:37 +0800 From: "william wallace" <avalonwallace@gmail.com> To: "Warner Losh" <imp@bsdimp.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: misc questions about the device&driver arch Message-ID: <87ab37ab0605201942o3e27c46w2ac57261e02a2890@mail.gmail.com> In-Reply-To: <20060520.013546.104050983.imp@bsdimp.com> References: <87ab37ab0605192015h363ef74aw23dcc2d97721dea9@mail.gmail.com> <20060519.232002.71106210.imp@bsdimp.com> <87ab37ab0605192239n73b7fcdbtbdd5dbd3f1099fc3@mail.gmail.com> <20060520.013546.104050983.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ? 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 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 <imp@bsdimp.com> wrote: > From: "william wallace" <avalonwallace@gmail.com> > 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 <imp@bsdimp.com> 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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87ab37ab0605201942o3e27c46w2ac57261e02a2890>