[Xen-devel] [PATCH 0/5] Printk symbol specifier

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

This series implements %ps and %pS, in the same way as Linux.

The first patch adds support to vsnprintf().  I audited all current uses of %p
and none would trigger the new codepath.

I was a little unsure about the best way of adding in support, so the patch is
a little RFC.

I used a switch statement to make it easier to add in further custom %p
support in the future (print hex buffer looks interesting), but forwent the
default case to reduce code motion.

The 128 byte namebuf on the stack is a tad unsavoury, but less so than a static
buffer with spinlock (which should have been included in the set of spinlocks
busted by console_force_unlock(), as printing symbols is very common on a
crash path).

The recursive call to snprintf is the least bad option available.  For the
basic string, I have copied the loop from the %s handler to save the
recursion.  Finally, all of the width specifier are ignored; I cant see a
reasonable usecase for them.


The second and third patches replace all uses of print_symbol() with %ps/%pS,
for x86 and arm respectively.  Most replacements are straight replacements,
but I have taken the opportunity to slightly cleanup the stack tracing code.
When two CPUs are racing at printing a stack, they contend on the console
spinlock, resulting in interleaving across end of the partial strings.  Now,
each full line of the stack trace is printed from a single printk(), so the
interleaving will occur at the line boundaries rather than mid-line
boundaries.

The fourth patch removes print_symbol() and friends, now that the
functionality has been completely replaced.

The fifth patch is not intended for committing, but for people wishing to test
and verify some of the boundary conditions.

Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
CC: Keir Fraser <keir@xxxxxxx>
CC: Jan Beulich <JBeulich@xxxxxxxx>
CC: Ian Campbell <ian.campbell@xxxxxxxxxx>
CC: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
CC: Tim Deegan <tim@xxxxxxx>

-- 
1.7.10.4


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel