misc questions about the device&driver arch

[M. Warner Losh]

In message: <87ab37ab0606040029u67edc35ende0b34e39e80bd37 at mail.gmail.com>
            "william wallace" <avalonwallace at gmail.com> writes:
: 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
: Prior to removing a card from the system, two things must occur:
: 
: The device's driver must cease accessing the card.
: 
: The card must cease generation transaction and interrupts.
: 
: How this is accomplished is OS-specific, but the following must take place:
: 
: The OS must stop issuing new requests to the device's driver or must
: instruct the driver to stop accepting new requests.
: 
: The driver must terminate or complete all outstanding requests.
: 
: The card must be disabled from generating interrupts or transactions.
: 
: When the OS commands the driver to quiesce itself and its device, the
: OS must not expect the device to remain in the system (in other words,
: it could be removed and not replaced with a similar card).
: 
: How to design and implement quiescing in freebsd?

device_quiesce?  I have it in a p4 tree right now.  Specifically, it
hooks up to the MOD_UNLOAD with a QUIESCE flag.  The driver's
device_quiesce routine gets called, the driver sleeps there until it
knows that it is good, then returns to the caller.  Then the driver's
detach routine can be called.

Warner