lkml.org 
[lkml]   [2008]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] x86: x86_{phys,virt}_bits field also for i386 (v3)
    Jan Beulich wrote:
    >> I would say the simplest thing to do here is be explicit:
    >>
    >> if (sizeof(addr) == sizeof(u64))
    >> return !(addr >> boot_cpu_data.x86_phys_bits);
    >> else
    >> return 1;
    >>
    >> That's not ideal, but I guess its good enough. I assume x86_phys_bits
    >> can never be less than 32?
    >>
    >
    > Yes, one could do it that way. But what's the point of having RESOURCES_64BIT
    > set and resource_size_t nevertheless being a 32-bit quantity?

    CONFIG_RESOURCES_64BIT was removed, so testing for it makes no sense.
    (Not being able to distinguish between non-existent and unset config
    variables is an outstanding Kconfig problem.)

    Directly testing the size of the type is the most robust approach,
    though it would be simpler if shifting a variable by more bits than its
    size had a guaranteed 0 result.

    > And why,
    > independent of that, was ioremap() not changed to use phys_addr_t?

    Well, ioremap is supposed to be used for IO mappings, so taking a
    resource_size_t still makes sense.

    The question of whether resource_size_t should be the same as a
    phys_addr_t is still a bit undecided. Andrew's of the opinion that they
    should be separate, and that it could make sense to have 32-bit resource
    addresses in an otherwise 64-bit system. I think that's a pretty narrow
    special case (32-bit PAE system with no 64-bit IO devices), and its not
    worth having the extra definition complexity for it.

    J


    \
     
     \ /
      Last update: 2008-09-19 23:49    [W:0.034 / U:0.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site