RFC: 64-bit resources and changes to pci, ioremap, ...

[Kumar Gala <kumar.gala@freescale.com>]

As I started to update the existing patches to make struct resource  
have 64-bit start and end values I started to see all the places that  
this effects and was hoping to get some discussion on what direction  
we want to take.
One of the main reasons to make this change is to handle processors  
that have larger physical address space than effective.  A number of  
higher-end embedded processors are starting to support larger  
physical address space while still having a 32-bit effective  
address.  I was wondering if any x86 variants support this type of  
feature?
The main issue that I'm starting to see is that the concept of a  
physical address from the processors point of view needs to be  
consistent throughout all subsystems of the kernel.  Currently the  
major usage of struct resource is with the PCI subsystem and PCI  
drivers.  The following are some questions that I was hoping to get  
answers to and discussion around:
* How many 32-bit systems support larger than 32-bit physical  
addresses (I know newer PPCs do)?
* How many 32-bit systems support a 64-bit PCI address space?
* Should ioremap and variants start taking 64-bit physical addresses?
* Do we make this an arch option and wrap start and end in a typedef  
similar to pte_t and provide accessor macros to ensure proper use?
Andrew has also asked me to post size comparisons of drivers/*/*.o  
building allmodconfig with 32-bit resources and 64-bit resources to  
see what the size growth is.  I'll post logs for people to take a  
look at in a followup email.
- Kumar
-
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/