Messages in this thread | | | From | "David S. Miller" <> | Date | Thu, 14 Jun 2001 07:42:29 -0700 (PDT) | Subject | Re: Going beyond 256 PCI buses |
| |
Jeff Garzik writes: > Why do you want to make the bus number larger than the PCI bus number > register?
This isn't it. What I'm trying to provoke thought on is "is there a way to make mindless apps using these syscalls work transparently"
I think the answer is no. Apps should really fetch info out of /proc/bus/pci and use the controller ioctl.
But someone could surprise me :-)
> It seems like adding 'unsigned int domain_num' makes more sense, and is > more correct. Maybe that implies fixing up other code to use a > (domain,bus) pair, but that's IMHO a much better change than totally > changing the interpretation of pci_bus::bus_number...
Correct, I agree. But I don't even believe we should be sticking the domain thing into struct pci_bus.
It's a platform thing. Most platforms have a single domain, so why clutter up struct pci_bus with this value? By this reasoning we could say that since it's arch-specific, this stuff belongs in sysdata or wherever.
And this is what is happening right now. So in essence, the work is done :-) The only "limiting factor" is that x86 doesn't support multiple domains as some other platforms do. So all these hot-plug patches just need to use domains properly, and perhaps add domain support to X86 when one of these hot-plug capable controllers are being used.
> > 2) Figure out what to do wrt. sys_pciconfig_{read,write}() > > 3) (tiny issue) Change pci_dev::slot_name such that it includes the > domain number. This is passed to userspace by SCSI and net drivers as a > way to allow userspace to associate a kernel interface with a bus > device.
Sure. It's an address and the domain is part of the address.
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/
| |