On Mon, 2012-07-02 at 20:32 +0300, Andy Shevchenko wrote:

On Sat, Jun 30, 2012 at 5:48 PM, Joe Perches [off-list ref] wrote:

quoted

On Fri, 2012-06-29 at 16:26 -0700, Andrew Morton wrote:

quoted

On Fri, 29 Jun 2012 09:08:06 -0700
Joe Perches [off-list ref] wrote:

quoted

quoted

diff --git a/lib/vsprintf.c b/lib/vsprintf.c

[]

quoted

@@ -655,11 +655,12 @@ char *resource_string(char *buf, char *end, struct resource *res,
 }

 static noinline_for_stack
-char *mac_address_string(char *buf, char *end, u8 *addr,
-                  struct printf_spec spec, const char *fmt)
+char *hex_string(char *buf, char *end, u8 *addr, struct printf_spec spec,
+          const char *fmt)
 {
- char mac_addr[sizeof("xx:xx:xx:xx:xx:xx")];
- char *p = mac_addr;
+ char hex_str[64*3];     /* support up to 64 bytes to print */

Might be too much stack though.

Yes, it's a bit marginal, as this new capability might be used in debug
or crash situations where we're deep into the stack.  The average case
could be improved by using alloca()-style allocation.

Or maybe support larger sizes with a smaller
stack buffer and a while loop.

What do you think about mixed approach? Let's say we would use buffer
on stack for 8 bytes or less, and allocated buffer in case of larger
input. It allows to keep implementation simple.

I think the while loop is simplest.
I'll code something up tomorrow unless
you get to it first.