misc questions about the device&driver arch

[M. Warner Losh]

In message: <87ab37ab0605300642ja608c97s24836a317cdac24 at mail.gmail.com>
            "william wallace" <avalonwallace at gmail.com> writes:
: Sir：
: I  have got the way to map linux pci access way to the BSD way :)
: now ,several more question ,wondering :(
: FIRST
: struct pci_devinfo * pci_read_device(device_t pcib, int b, int s, int
: f, size_t size)
: struct cardbus_devinfo {
: 	struct pci_devinfo pci;
: 	uint8_t        mprefetchable; /* bit mask of prefetchable BARs */
: 
: so what happen when dinfo = (struct cardbus_devinfo
: *)pci_read_device(brdev, bus, slot, func, sizeof(struct
: cardbus_devinfo));
: can we use this magic as a common way to wrap common guts?

Yes.  It is already there when you go throuh the proper interface.
Take a look at ivars.  struct pci_devinfo is not for anybody but a bus
to use.

: SECOND
: what should we do to destroy a device and hot remove it from the system ?
: 1 pause the application

impractical.  What application?  This is an async event, and upper
level drivers have to cope.  If they don't, we're screwed anyway.  If
a device can disappear, then we have to make sure that the drivers
support it.

: 2 device_detach(devlist[tmp]);

That's what we do right now in cardbus.

: 3***_release_all_resources(busdev, dinfo);

Drivers are responsible for doing this, not the bus.

: 4 device_delete_child(busdev, devlist[tmp]);

That's what we do right now in cardbus.

: 5 pci_freecfg((struct pci_devinfo *)dinfo);

Sounds good.

: 6 shutdown power of the slot

Yea.

: so what exactly happens between 2 and 5?

: THIRD
: Because the PCIE configure space is 4k long ,shall we change the
: #define PCI_REGMAX	255
: to facilitate the PCI express config R/W?

Maybe.  Lemme investigate because PCIe changes this from a well known
constant for all pci busses, to a variable one...

Warner