[RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

Sergey Senozhatsky sergey.senozhatsky at gmail.com
Fri Oct 20 01:11:24 AEDT 2017


Michael,

On (09/27/17 15:01), Michael Ellerman wrote:
> Sergey Senozhatsky <sergey.senozhatsky.work at gmail.com> writes:
> 
> > On (09/22/17 16:48), Luck, Tony wrote:
> > [..]
> >> Tested patch series on ia64 successfully.
> >> 
> >> Tested-by: Tony Luck <tony.luck at intel.com>
> >
> > thanks!
> >
> >> After this goes upstream, you should submit a patch to get rid of
> >> all uses of %pF (70 instances in 35 files) and %pf (63 in 34)
> >> 
> >> Perhaps break the patch by top-level directory (e.g. get all the %pF
> >> and %pF in the 17 files under drivers/ in one patch).
> >
> > frankly, I was going to have some sort of a lazy deprecation process:
> > didn't plan to send out a patch set that would hunt down all pf/pF-s.
> > hm...
> 
> That never works though, we have lots of cruft left over from times when
> that's happened and the conversion never quite got finished.

this time around it's different, I promise! :)


well...
I guess I can send out a tree wide pf/pF removal patch set. later.
when we will see that .opd based dereference does not make anyone
unhappy.

and I think we can't remove pf/pF from the kernel completely. it
will stay in vscnprintf() for some time. old habits die hard, I suppose,
there might be people using it for debugging/etc.


> At least if you send out the patches to do the removal they might
> eventually get merged.
> 
> > speaking of upstream, any objections if this patch set will go through
> > the printk tree, in one piece?
> 
> Do you mind putting it in a topic branch (based on rc2) and then merge
> that into the printk tree? That way I can merge the topic branch iff
> there are conflicts later down the line towards 4.15.

ok, let me re-spin the series. there are some changes here
and there, so I'll drop Tested-by/Reviewed-by tags and will
ask platforms' maintainers to re-test the patch set :(

if everything goes OK, then we can ask Petr to do the topic
branch (I don't have a kernel.org account).

	-ss


More information about the Linuxppc-dev mailing list