Messages in this thread |  | | From | "David S. Miller" <> | Date | Thu, 14 Jun 2001 07:24:48 -0700 (PDT) | Subject | Re: Going beyond 256 PCI buses |
| |
Jeff Garzik writes: > According to the PCI spec it is -impossible- to have more than 256 buses > on a single "hose", so you simply have to implement multiple hoses, just > like Alpha (and Sparc64?) already do. That's how the hardware is forced > to implement it...
Right, what userspace had to become aware of are "PCI domains" which is just another fancy term for a "hose" or "controller".
All you have to do is (right now, the kernel supports this fully) open up a /proc/bus/pci/${BUS}/${DEVICE} node and then go:
domain = ioctl(fd, PCIIOC_CONTROLLER, 0);
Viola.
There are only two real issues:
1) Extending the type bus numbers use inside the kernel.
Basically how most multi-controller platforms work now is they allocate bus numbers in the 256 bus space as controllers are probed. If we change the internal type used by the kernel to "u32" or whatever, we expand that available space accordingly.
For the lazy, basically go into include/linux/pci.h and change the "unsigned char"s in struct pci_bus into some larger type. This is mindless work.
2) Figure out what to do wrt. sys_pciconfig_{read,write}()
They ought to really be deprecated and the /proc/bus/pci way is the expected way to go about doing these things. The procfs interface is more intelligent, less clumsy, and even allows you to mmap() PCI cards portably (instead of doing crap like mmap()s on /dev/mem, yuck).
Actually, there only real issue here is what happens when userspace does PCI config space reads to things which talk about "bus numbers" since those will be 8-bit as this is a hardware imposed type. These syscalls take long args already so they could use >256 bus numbers just fine.
Basically, this 256 bus limit in Linux is a complete fallacy.
Later, David S. Miller davem@redhat.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |