On Mon, 2018-11-26 at 15:08 +0900, Sergey Senozhatsky wrote: > > There are approximately these total uses of the symbolic > > lookup vsprintf extensions %p[SsFf]: > > > > $ git grep '".*[^%]%p[SsFf]' | \ > > grep -oh '%p[SsFf]' | sort | uniq -c | sort -rn > > 231 %pS > > 65 %ps > > 60 %pf > > 47 %pF > > I didn't bother to remove "pf/pF" because I didn't want to count on: > a) everyone running checkpatch.pl > b) everyone testing all printk-s they added > > I guess pf/pF still can sneak in.
Any use of %p<invalid_extension> could sneak in. And thanks, the checkpatch test for %p<invalid_extensions> should be updated too. > But I don't have a really strong opinion on this. If general > consensus is that we shall remove deprecated specifiers, then > I'm fine. I think converting deprecated things is generally good. Also, the %p<extension> lettering space is limited, so cleaning deprecated extensions is useful. > After running this script I still have a bunch of leftovers: > > // > // these two are probably not really relevant, but still - %pF/%pf > // > tools/lib/traceevent/event-parse.c: if (asprintf(&format, "%%pf: > (NO FORMAT FOUND at %llx)\n", addr) < 0) > tools/lib/traceevent/event-parse.c: if (asprintf(&format, "%s: %s", > "%pf", printk->printk) < 0) I was not/am not sure about those. > arch/um/kernel/sysrq.c: pr_info(" [<%08lx>] %s%pF\n", address, reliable ? "" > : "? ", > arch/x86/xen/multicalls.c: printk(KERN_DEBUG " > call %2d/%d: op=%lu arg=[%lx] result=%ld\t%pF\n", > kernel/async.c: pr_debug("calling %lli_%pF @ %i\n", > kernel/async.c: pr_debug("initcall %lli_%pF returned 0 after %lld > usecs\n", Missed those by using \b, thanks again.