lkml.org 
[lkml]   [2005]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRFC: 64-bit resources and changes to pci, ioremap, ...
Date
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/

\
 
 \ /
  Last update: 2005-07-29 18:00    [W:0.042 / U:2.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site