misc questions about the device&driver arch

[John-Mark Gurney]

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 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?$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 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...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."