On Tue, 2013-01-22 at 23:26 +0100, Geert Uytterhoeven wrote:
On Tue, Jan 22, 2013 at 6:47 AM, Stepan Moskovchenko
<stepanm@xxxxxxxxxxxxxx> wrote:
> Add the %pa format specifier for printing a phys_addr_t
> type, since the physical address size on some platforms
> can vary based on build options, regardless of the native
> integer type.
I'm not so sure it's a good idea to start using %p for integer types.
It would also require that some automatic variables
that could otherwise be used in registers be put on
the stack.
When calling something like printk on a variable, is that really a big
concern in the grand scheme of things? On a system with a 32-bit
phys_addr_t type, how does the overhead of having to put the variable on
the stack compare to the overhead needed to cast to an unsigned long
long and emit the eight extra '0' characters when printing a formatted
physical address? If allocation efficiency is a big concern for a
particular code path, the caller is always free to continue to cast to
unsigned long long and use %llu, if they don't mind extra padding where
phys_addr_t is smaller than a long long. But considering this is
primarily meant to be used by printk during initialization / debug /
error handling paths, there will be plenty of other overhead involved in
producing log output.
As far as type safety is concerned, the %p specifier is already willing
to accept pointers to all sorts of things which it is powerless to
check, and it is up to the caller to do the right thing.
Printing out a physical address is a pretty reasonable thing for a
driver to do in an init or debug path. It is conceivable that the same
driver may be used on a system with 32-bit ore >32-bit physical address
types. With something like ARM LPAE, it is even possible for the same
system to use 32-bit and >32-bit addressing based strictly on build
options, while still using the same drivers, meaning that the drivers
would need to deal with phys_addr_t being of variable size. It also
seems like a potential bit of extra overhead is not worth the ugliness
of casting each phys_addr_t to an unsigned long long and printing it as
a 64-bit type regardless of the actual number of address bits available.
If a driver is really concerned about efficiency of its init paths, it
is free to continue using %llu, or better yet, cut down on the amount of
log spam these paths generate.
Steve
--
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
