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

    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-07-29 18:00    [W:0.021 / U:0.560 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site