* [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types
@ 2013-01-22 5:47 Stepan Moskovchenko
2013-01-22 7:29 ` Andy Shevchenko
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Stepan Moskovchenko @ 2013-01-22 5:47 UTC (permalink / raw)
To: Rob Landley, Andrew Morton, George Spelvin, Andy Shevchenko,
Stephen Boyd, Andrei Emeltchenko, mingo
Cc: linux-doc, linux-kernel, linux-arm-msm, Stepan Moskovchenko
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.
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
---
Documentation/printk-formats.txt | 13 ++++++++++---
lib/vsprintf.c | 7 +++++++
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 8ffb274..dbc977b 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -53,6 +53,13 @@ Struct Resources:
For printing struct resources. The 'R' and 'r' specifiers result in a
printed resource with ('R') or without ('r') a decoded flags member.
+Physical addresses:
+
+ %pa 0x01234567 or 0x0123456789abcdef
+
+ For printing a phys_addr_t type, which can vary based on build options,
+ regardless of the width of the CPU data path. Passed by reference.
+
Raw buffer as a hex string:
%*ph 00 01 02 ... 3f
%*phC 00:01:02: ... :3f
@@ -150,9 +157,9 @@ s64 SHOULD be printed with %lld/%llx, (long long):
printk("%lld", (long long)s64_var);
If <type> is dependent on a config option for its size (e.g., sector_t,
-blkcnt_t, phys_addr_t, resource_size_t) or is architecture-dependent
-for its size (e.g., tcflag_t), use a format specifier of its largest
-possible type and explicitly cast to it. Example:
+blkcnt_t, resource_size_t) or is architecture-dependent for its size (e.g.,
+tcflag_t), use a format specifier of its largest possible type and explicitly
+cast to it. Example:
printk("test: sector number/total blocks: %llu/%llu\n",
(unsigned long long)sector, (unsigned long long)blockcount);
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 39c99fe..9b02a71 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1022,6 +1022,7 @@ int kptr_restrict __read_mostly;
* N no separator
* The maximum supported length is 64 bytes of the input. Consider
* to use print_hex_dump() for the larger input.
+ * - 'a' For a phys_addr_t type (passed by reference)
*
* Note: The difference between 'S' and 'F' is that on ia64 and ppc64
* function pointers are really function descriptors, which contain a
@@ -1112,6 +1113,12 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
return netdev_feature_string(buf, end, ptr, spec);
}
break;
+ case 'a':
+ spec.flags |= SPECIAL | SMALL | ZEROPAD;
+ spec.field_width = sizeof(phys_addr_t) * 2;
+ spec.base = 16;
+ return number(buf, end,
+ (unsigned long long) *((phys_addr_t *)ptr), spec);
}
spec.flags |= SMALL;
if (spec.field_width == -1) {
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types
2013-01-22 5:47 [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types Stepan Moskovchenko
@ 2013-01-22 7:29 ` Andy Shevchenko
2013-01-22 7:52 ` Joe Perches
2013-01-22 22:26 ` Geert Uytterhoeven
2013-01-23 0:14 ` [PATCH v2] " Stepan Moskovchenko
2 siblings, 1 reply; 12+ messages in thread
From: Andy Shevchenko @ 2013-01-22 7:29 UTC (permalink / raw)
To: Stepan Moskovchenko
Cc: Rob Landley, Andrew Morton, George Spelvin, Stephen Boyd,
Andrei Emeltchenko, mingo, linux-doc, linux-kernel,
linux-arm-msm
On Mon, 2013-01-21 at 21:47 -0800, Stepan Moskovchenko 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.
>
> Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
> ---
> Documentation/printk-formats.txt | 13 ++++++++++---
> lib/vsprintf.c | 7 +++++++
> 2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
> index 8ffb274..dbc977b 100644
> --- a/Documentation/printk-formats.txt
> +++ b/Documentation/printk-formats.txt
> @@ -53,6 +53,13 @@ Struct Resources:
> For printing struct resources. The 'R' and 'r' specifiers result in a
> printed resource with ('R') or without ('r') a decoded flags member.
>
> +Physical addresses:
> +
> + %pa 0x01234567 or 0x0123456789abcdef
> +
> + For printing a phys_addr_t type, which can vary based on build options,
> + regardless of the width of the CPU data path. Passed by reference.
> +
> Raw buffer as a hex string:
> %*ph 00 01 02 ... 3f
> %*phC 00:01:02: ... :3f
> @@ -150,9 +157,9 @@ s64 SHOULD be printed with %lld/%llx, (long long):
> printk("%lld", (long long)s64_var);
>
> If <type> is dependent on a config option for its size (e.g., sector_t,
> -blkcnt_t, phys_addr_t, resource_size_t) or is architecture-dependent
> -for its size (e.g., tcflag_t), use a format specifier of its largest
> -possible type and explicitly cast to it. Example:
> +blkcnt_t, resource_size_t) or is architecture-dependent for its size (e.g.,
resource_size_t is a typedef of phys_addr_t.
Probably you should mention that your change related to the phys_addr_t
*and* derivatives.
> +tcflag_t), use a format specifier of its largest possible type and explicitly
> +cast to it. Example:
>
> printk("test: sector number/total blocks: %llu/%llu\n",
> (unsigned long long)sector, (unsigned long long)blockcount);
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 39c99fe..9b02a71 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1022,6 +1022,7 @@ int kptr_restrict __read_mostly;
> * N no separator
> * The maximum supported length is 64 bytes of the input. Consider
> * to use print_hex_dump() for the larger input.
> + * - 'a' For a phys_addr_t type (passed by reference)
> *
> * Note: The difference between 'S' and 'F' is that on ia64 and ppc64
> * function pointers are really function descriptors, which contain a
> @@ -1112,6 +1113,12 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
> return netdev_feature_string(buf, end, ptr, spec);
> }
> break;
> + case 'a':
> + spec.flags |= SPECIAL | SMALL | ZEROPAD;
> + spec.field_width = sizeof(phys_addr_t) * 2;
> + spec.base = 16;
> + return number(buf, end,
> + (unsigned long long) *((phys_addr_t *)ptr), spec);
> }
> spec.flags |= SMALL;
> if (spec.field_width == -1) {
> --
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
>
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types
2013-01-22 7:29 ` Andy Shevchenko
@ 2013-01-22 7:52 ` Joe Perches
2013-01-22 21:07 ` Stepan Moskovchenko
0 siblings, 1 reply; 12+ messages in thread
From: Joe Perches @ 2013-01-22 7:52 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Stepan Moskovchenko, Rob Landley, Andrew Morton, George Spelvin,
Stephen Boyd, Andrei Emeltchenko, mingo, linux-doc, linux-kernel,
linux-arm-msm
On Tue, 2013-01-22 at 09:29 +0200, Andy Shevchenko wrote:
> On Mon, 2013-01-21 at 21:47 -0800, Stepan Moskovchenko 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.
[]
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
[]
> @@ -1112,6 +1113,12 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
> > return netdev_feature_string(buf, end, ptr, spec);
> > }
> > break;
> > + case 'a':
> > + spec.flags |= SPECIAL | SMALL | ZEROPAD;
> > + spec.field_width = sizeof(phys_addr_t) * 2;
I believe this should be:
spec.field_width = sizeof(phys_addr_t) * 2 + 2;
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types
2013-01-22 7:52 ` Joe Perches
@ 2013-01-22 21:07 ` Stepan Moskovchenko
0 siblings, 0 replies; 12+ messages in thread
From: Stepan Moskovchenko @ 2013-01-22 21:07 UTC (permalink / raw)
To: Joe Perches
Cc: Andy Shevchenko, Rob Landley, Andrew Morton, George Spelvin,
Stephen Boyd, Andrei Emeltchenko, mingo, linux-doc, linux-kernel,
linux-arm-msm
On 1/21/2013 11:52 PM, Joe Perches wrote:
> I believe this should be:
>
> spec.field_width = sizeof(phys_addr_t) * 2 + 2;
>
Ah yes, I believe you are right. I had only added the SPECIAL flag after
writing this. Will fix in v2.
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types
2013-01-22 5:47 [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types Stepan Moskovchenko
2013-01-22 7:29 ` Andy Shevchenko
@ 2013-01-22 22:26 ` Geert Uytterhoeven
2013-01-23 4:14 ` Joe Perches
2013-01-23 0:14 ` [PATCH v2] " Stepan Moskovchenko
2 siblings, 1 reply; 12+ messages in thread
From: Geert Uytterhoeven @ 2013-01-22 22:26 UTC (permalink / raw)
To: Stepan Moskovchenko
Cc: Rob Landley, Andrew Morton, George Spelvin, Andy Shevchenko,
Stephen Boyd, Andrei Emeltchenko, mingo, linux-doc, linux-kernel,
linux-arm-msm
On Tue, Jan 22, 2013 at 6:47 AM, Stepan Moskovchenko
<stepanm@codeaurora.org> 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.
For structures like MAC addresses, it makes life easier.
%p offers very minimal support from the compiler for checking the argument type.
At least with casting to "unsigned long long" and using %llu not much can go
wrong if there are no compiler warnings.
Also variables holding MAC address typically don't change, while there's been
lots of churn in variables changing type from unsigned long to phys_addr_t or
unsigned long long or void *. Without help of the compiler to catch
incorrect format
specifiers, it will become much more difficult to get and keep all of
them correct.
Just my two (euro)cents...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2] lib: vsprintf: Add %pa format specifier for phys_addr_t types
2013-01-22 5:47 [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types Stepan Moskovchenko
2013-01-22 7:29 ` Andy Shevchenko
2013-01-22 22:26 ` Geert Uytterhoeven
@ 2013-01-23 0:14 ` Stepan Moskovchenko
2013-01-24 23:07 ` Andrew Morton
2013-02-07 4:39 ` Rob Landley
2 siblings, 2 replies; 12+ messages in thread
From: Stepan Moskovchenko @ 2013-01-23 0:14 UTC (permalink / raw)
To: Rob Landley, Andrew Morton, George Spelvin, Andy Shevchenko,
Stephen Boyd, Andrei Emeltchenko, mingo
Cc: linux-doc, linux-kernel, linux-arm-msm, Stepan Moskovchenko
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@codeaurora.org>
---
v2: - Update field width to make room for the '0x' prefix
- Update documentation to include derivative types
Documentation/printk-formats.txt | 14 +++++++++++---
lib/vsprintf.c | 7 +++++++
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 8ffb274..e8a6aa4 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -53,6 +53,14 @@ Struct Resources:
For printing struct resources. The 'R' and 'r' specifiers result in a
printed resource with ('R') or without ('r') a decoded flags member.
+Physical addresses:
+
+ %pa 0x01234567 or 0x0123456789abcdef
+
+ For printing a phys_addr_t type (and its derivatives, such as
+ resource_size_t) which can vary based on build options, regardless of
+ the width of the CPU data path. Passed by reference.
+
Raw buffer as a hex string:
%*ph 00 01 02 ... 3f
%*phC 00:01:02: ... :3f
@@ -150,9 +158,9 @@ s64 SHOULD be printed with %lld/%llx, (long long):
printk("%lld", (long long)s64_var);
If <type> is dependent on a config option for its size (e.g., sector_t,
-blkcnt_t, phys_addr_t, resource_size_t) or is architecture-dependent
-for its size (e.g., tcflag_t), use a format specifier of its largest
-possible type and explicitly cast to it. Example:
+blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a
+format specifier of its largest possible type and explicitly cast to it.
+Example:
printk("test: sector number/total blocks: %llu/%llu\n",
(unsigned long long)sector, (unsigned long long)blockcount);
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 39c99fe..6e62c3f 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1022,6 +1022,7 @@ int kptr_restrict __read_mostly;
* N no separator
* The maximum supported length is 64 bytes of the input. Consider
* to use print_hex_dump() for the larger input.
+ * - 'a' For a phys_addr_t type and its derivative types (passed by reference)
*
* Note: The difference between 'S' and 'F' is that on ia64 and ppc64
* function pointers are really function descriptors, which contain a
@@ -1112,6 +1113,12 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
return netdev_feature_string(buf, end, ptr, spec);
}
break;
+ case 'a':
+ spec.flags |= SPECIAL | SMALL | ZEROPAD;
+ spec.field_width = sizeof(phys_addr_t) * 2 + 2;
+ spec.base = 16;
+ return number(buf, end,
+ (unsigned long long) *((phys_addr_t *)ptr), spec);
}
spec.flags |= SMALL;
if (spec.field_width == -1) {
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types
2013-01-22 22:26 ` Geert Uytterhoeven
@ 2013-01-23 4:14 ` Joe Perches
2013-01-24 0:37 ` Stepan Moskovchenko
0 siblings, 1 reply; 12+ messages in thread
From: Joe Perches @ 2013-01-23 4:14 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stepan Moskovchenko, Rob Landley, Andrew Morton, George Spelvin,
Andy Shevchenko, Stephen Boyd, Andrei Emeltchenko, mingo,
linux-doc, linux-kernel, linux-arm-msm
On Tue, 2013-01-22 at 23:26 +0100, Geert Uytterhoeven wrote:
> On Tue, Jan 22, 2013 at 6:47 AM, Stepan Moskovchenko
> <stepanm@codeaurora.org> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types
2013-01-23 4:14 ` Joe Perches
@ 2013-01-24 0:37 ` Stepan Moskovchenko
0 siblings, 0 replies; 12+ messages in thread
From: Stepan Moskovchenko @ 2013-01-24 0:37 UTC (permalink / raw)
To: Joe Perches
Cc: Geert Uytterhoeven, Stepan Moskovchenko, Rob Landley,
Andrew Morton, George Spelvin, Andy Shevchenko, Stephen Boyd,
Andrei Emeltchenko, mingo, linux-doc, linux-kernel,
linux-arm-msm
> On Tue, 2013-01-22 at 23:26 +0100, Geert Uytterhoeven wrote:
>> On Tue, Jan 22, 2013 at 6:47 AM, Stepan Moskovchenko
>> <stepanm@codeaurora.org> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] lib: vsprintf: Add %pa format specifier for phys_addr_t types
2013-01-23 0:14 ` [PATCH v2] " Stepan Moskovchenko
@ 2013-01-24 23:07 ` Andrew Morton
2013-02-07 4:39 ` Rob Landley
1 sibling, 0 replies; 12+ messages in thread
From: Andrew Morton @ 2013-01-24 23:07 UTC (permalink / raw)
To: Stepan Moskovchenko
Cc: Rob Landley, George Spelvin, Andy Shevchenko, Stephen Boyd,
Andrei Emeltchenko, mingo, linux-doc, linux-kernel,
linux-arm-msm
On Tue, 22 Jan 2013 16:14:53 -0800
Stepan Moskovchenko <stepanm@codeaurora.org> 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.
Looks sane.
Now, how do we hunt down the existing callsites which can be converted
to use this?
It would be nice to change at least a few of them right now, so your
patch gets tested. Common x86 ones, ideally.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] lib: vsprintf: Add %pa format specifier for phys_addr_t types
2013-01-23 0:14 ` [PATCH v2] " Stepan Moskovchenko
@ 2013-02-07 4:39 ` Rob Landley
2013-02-07 4:39 ` Rob Landley
1 sibling, 0 replies; 12+ messages in thread
From: Rob Landley @ 2013-02-07 4:39 UTC (permalink / raw)
Cc: Andrew Morton, George Spelvin, Andy Shevchenko, Stephen Boyd,
Andrei Emeltchenko, mingo, linux-doc, linux-kernel,
linux-arm-msm, Stepan Moskovchenko
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@codeaurora.org>
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?
Rob
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] lib: vsprintf: Add %pa format specifier for phys_addr_t types
@ 2013-02-07 4:39 ` Rob Landley
0 siblings, 0 replies; 12+ messages in thread
From: Rob Landley @ 2013-02-07 4:39 UTC (permalink / raw)
To: Stepan Moskovchenko
Cc: Andrew Morton, George Spelvin, Andy Shevchenko, Stephen Boyd,
Andrei Emeltchenko, mingo, linux-doc, linux-kernel,
linux-arm-msm, Stepan Moskovchenko
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@codeaurora.org>
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?
Rob
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2] lib: vsprintf: Add %pa format specifier for phys_addr_t types
2013-02-07 4:39 ` Rob Landley
(?)
@ 2013-02-07 6:39 ` Geert Uytterhoeven
-1 siblings, 0 replies; 12+ messages in thread
From: Geert Uytterhoeven @ 2013-02-07 6:39 UTC (permalink / raw)
To: Rob Landley
Cc: Stepan Moskovchenko, Andrew Morton, George Spelvin,
Andy Shevchenko, Stephen Boyd, Andrei Emeltchenko, mingo,
linux-doc, linux-kernel, linux-arm-msm
Hi Rob,
On Thu, Feb 7, 2013 at 5:39 AM, Rob Landley <rob@landley.net> 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@codeaurora.org>
>
>
> 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@linux-m68k.org
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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-02-07 6:39 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-22 5:47 [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_t types Stepan Moskovchenko
2013-01-22 7:29 ` Andy Shevchenko
2013-01-22 7:52 ` Joe Perches
2013-01-22 21:07 ` Stepan Moskovchenko
2013-01-22 22:26 ` Geert Uytterhoeven
2013-01-23 4:14 ` Joe Perches
2013-01-24 0:37 ` Stepan Moskovchenko
2013-01-23 0:14 ` [PATCH v2] " Stepan Moskovchenko
2013-01-24 23:07 ` Andrew Morton
2013-02-07 4:39 ` Rob Landley
2013-02-07 4:39 ` Rob Landley
2013-02-07 6:39 ` Geert Uytterhoeven
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.