misc questions about the device&driver arch

[william wallace]

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 at bsdimp.com> wrote:
> From: "william wallace" <avalonwallace at 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 at 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!