Using any network interface whatsoever

[Bruce M Simpson]

On Sun, Apr 09, 2006 at 06:48:25PM -0600, M. Warner Losh wrote:
> I though thtis was already supported.  We export bus/slot/function
> information devd, which can be used to configure the device.

If I've read the specs or code incorrectly please do let me know --
my reading here is based on the PCI code as I understand it to be.

As I understand things, the bus/slot/function numbers in pci(9), the
*slot* number isn't guaranteed to have any meaning in geographic reality;
it's purely what the PCI logic thinks the bus topology looks like and
hence what the device numbers are. See BUGS in pci(9).

It won't tell you that a given card is in a given slot with any degree
of certainty or consistency across the range of backplanes available
from multiple vendors -- although people may like to give PICMG a try
as I hear such boards are consistent about such things.

In the old Microsoft-specified $PIR tables there was a column which
allowed you to map the bus/device/function tuple we use to a physical
slot number, but this only ran 1-6. With multiple PCI buses and slot
types, as well as multifunction devices, this information quickly became
unusable and unreliable, although src/tools/tools/pirtool will happily
display this information.

ACPI as you no doubt know does away with the $PIR tables, although many
BIOS still export them to allow legacy DOS programs which use PCI to work.
There is an extension to ACPI which adds geographical slot addressing
to the device tree but I haven't seen any systems which support it.

Regards,
BMS

P.S. I have some notes somewhere about the ACPI geog stuff but can't
remember if I posted them or filed them elsewhere -- check the XORP
mailing lists, I think we bashed this out there around 14 months ago.