Stefan Reinauer <[EMAIL PROTECTED]> writes: > * Eric W. Biederman <[EMAIL PROTECTED]> [040601 09:53]: > > Essentially. Although the pci devices don't vanish you likely can't use > > them because some of their BARS have values that 32bit kernels can't > > cope with. lspci should let you see that though. A 32bit kernel > > with PAE enabled could code but no one has written the code. > > Are there any drawbacks to that solution? This should be addressed to > the Linux kernel developers. Given the advantages this brings, this > would probably something people would like to see.
struct resource {} needs to be defined in terms of u64 instead of unsigned long. I know just that tweak was discussed and there were some problems with that. > > I don't have a problem with adding an option to disable this for 32bit > > kernels. I am just tired of optimizing 64bit machines for 32bit > > kernels. > > The silver bullet would be an option in the cmos option table to trigger > the one or the other behaviour. Right that is what I was thinking. > Or maybe it is enough to just put the > PCI BARs into 32bit address space whenever it fits there, taking the > amount of RAM into regard. Except for some very small filters that starts requiring a filter that is too smart. I think ultimately it is going to the bridge bars that are going to limit me. So I may only be able to apply this to prefetchable memory regions. But that should still cover the large mmio regions with 64bit BARs. > I agree it does not make sense to _optimize_ for 32bit kernels. > Essentially there are two groups of potential LinuxBIOS users in this > case: Those with small amounts of RAM (ie amd64 based embedded > solutions) might use 32bit code because it's easy to test it on many > PCs. Those with large amounts of RAM don't want to use a 32bit kernel > anyways. With more than about 1G of RAM 32bit Linux performance breaks > down noticably compared to the 64bit variant. Interesting. Most of my customers have compute intensive apps and I don't think see the break down anywhere near that soon. Eric _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios