On Wed, 15 Oct 2003, Jon Smirl wrote:
> 
> If you are familar with the hardware please check that I got the PCI ID lists
> right.

Please fix the fact that modern PCI is _not_ enumerated with just "bus,
slot, function". A lot of machines are starting to have a "domain number", 
which allows fro multiple independent PCI subsystems in the same machine.

On linux, you can use "pci_name(pdev)" to get a truly unique descriptor of
the device (within the PCI subsystem). It will look something like

        0000:00:02.0

for "domain 0, bus 0, device 2, function 0".

In fact, for future sanity, it makes sense to not only have the location, 
but the bus _type_ there too. Some day, maybe we won't all be using PCI 
enumeration, and it really makes sense to prepare for that by explicitly 
saying what _kind_ of address it is. 

So if you have a "struct pci_device *dev", then to uniquely identify it 
among all other devices, use something like

        snprintf(name, sizeof(name), "pci%s", pci_name(dev));

which will allow you to use the same naming at some later day when/if you 
want to support something else. In other words, if you were to support 
sbus, you would have

        struct sbus_device = find_sbus_device(...)

        snprintf(name, sizeof(name), "sbus%s", sbus_name(dev));

and the name would still be unique, and you can easily parse it to see 
what kind of device it is and where it is (even though different buses 
will have different notions of what "where" is).

(Yeah, yeah, you're only supporting PCI-mapped devices now - even the AGP 
stuff obviously shows up in the PCI namespace. That doesn't mean that you 
should design the interfaces to only handle PCI).

                Linus



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to