Date: Sat, 20 May 2006 20:07:25 -0700 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: william wallace <avalonwallace@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: misc questions about the device&driver arch Message-ID: <20060521030725.GD770@funkthat.com> In-Reply-To: <87ab37ab0605201942o3e27c46w2ac57261e02a2890@mail.gmail.com> References: <87ab37ab0605192015h363ef74aw23dcc2d97721dea9@mail.gmail.com> <20060519.232002.71106210.imp@bsdimp.com> <87ab37ab0605192239n73b7fcdbtbdd5dbd3f1099fc3@mail.gmail.com> <20060520.013546.104050983.imp@bsdimp.com> <87ab37ab0605201942o3e27c46w2ac57261e02a2890@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
william wallace wrote this message on Sun, May 21, 2006 at 10:42 +0800:
> 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 ?
If there isn't one implemented, it just falls back to kobj_error_method,
which simply returns ENXIO...
> 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),
Look at how it's called:
nclaptop,ttyp5,~/FreeBSD/HEAD/src/sys/isa,557$grep BUS_ADD_CHILD *
isahint.c: child = BUS_ADD_CHILD(parent, order, name, unit);
orm.c: child = BUS_ADD_CHILD(parent, ISA_ORDER_SENSITIVE, "orm", -1);
as you can see, you just provide the probe order, the name and unit of
the device you're adding... The call to BUS_ADD_CHILD is necessary for
busses that use identify methods... this ensures that things like
ivars are setup properly by the bus for the device..
> 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?$B!$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).
> >
> >> 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...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060521030725.GD770>