From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 10 20:13:56 2006 Return-Path: X-Original-To: hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 776D716A406 for ; Mon, 10 Apr 2006 20:13:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FDFA43D45 for ; Mon, 10 Apr 2006 20:13:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k3AKAa4w044559; Mon, 10 Apr 2006 14:10:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 10 Apr 2006 14:10:42 -0600 (MDT) Message-Id: <20060410.141042.25162164.imp@bsdimp.com> To: bms@spc.org From: "M. Warner Losh" In-Reply-To: <20060410194746.GY80492@spc.org> References: <20060409090757.GW80492@spc.org> <20060409.184825.99254285.imp@bsdimp.com> <20060410194746.GY80492@spc.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mwm-keyword-freebsdhackers.102a7e@mired.org, scottl@samsco.org, ceri@submonkey.net, hackers@FreeBSD.org Subject: Re: Using any network interface whatsoever X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2006 20:13:56 -0000 In message: <20060410194746.GY80492@spc.org> Bruce M Simpson writes: : 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). The device number is fixed for a given mother board slot. It will never change unless you change the mother board. However, for stacking topologies the slot is the position in the stack. : 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. Correct. : 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. Correct. : 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. OK. Physical slot information. Warner