Hi Rob, On Thu, Feb 7, 2013 at 5:39 AM, Rob Landley <rob@xxxxxxxxxxx> wrote: > On 01/22/2013 06:14:53 PM, Stepan Moskovchenko wrote: >> Add the %pa format specifier for printing a phys_addr_t >> type and its derivative types (such as resource_size_t), >> since the physical address size on some platforms can vary >> based on build options, regardless of the native integer >> type. >> >> Signed-off-by: Stepan Moskovchenko <stepanm@xxxxxxxxxxxxxx> > > > Ok, I know I'm late to the party, but doesn't LP64 apply here? Are we really > capable of building on a target where "long" and "pointer" are different > sizes? Last I checked the kernel was full of that assumption because there > was an actual standard and we demanded that the compiler building us comply > with it, just like MacOS X and the BSDs do: > > Standard: > http://www.unix.org/whitepapers/64bit.html > > Rationale: > http://www.unix.org/version2/whatsnew/lp64_wp.html > > Insane legacy reasons Windows decided to be "special": > http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx > > Thus "unsigned long" should by definition be big enough. Using unsigned long > long means you're doing 64 bit math on 32 bit targets for no apparent > reason. > > What did I miss? This is about phys_addr_t and resource_size_t, which are _physical_ addresses, not virtual adresses. Virtual addresses are still 32-bit, so unsigned long is fine for them. But these days several CPUs have 36-bit physical addresses, which don't fit in unsigned long. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
