Re: [PATCH V3] mm: Standardize printing for pgtable entries

[Andy Shevchenko]

On Thu, Jul 09, 2026 at 04:42:30PM +0530, Anshuman Khandual wrote:
> On 09/07/26 4:13 PM, Andy Shevchenko wrote:
> > On Thu, Jul 09, 2026 at 12:24:08PM +0200, David Hildenbrand (Arm) wrote:
> >> On 7/9/26 12:13, Andy Shevchenko wrote:
> >>> On Thu, Jul 09, 2026 at 01:11:46PM +0300, Andy Shevchenko wrote:
> >>>> On Thu, Jul 09, 2026 at 11:15:27AM +0200, Petr Mladek wrote:

...

> >>>>> But maybe you had something particular in mind.
> >>>>
> >>>> Yes, I was thinking of a wrapper on top of special_hex_number(). It takes size
> >>>> as an argument and hence will work even for 128-bit cases.
> >>>
> >>> Okay, the argument is limited to 64-bit in there. But I don't think it's a big
> >>> impediment.
> >>
> >> Rewrite number() / create a new 128bit variants to avoid 3 simple snprintf()
> >> statements? :)
> >>
> >> Hm ...
> > 
> > Since it's slowly spreading (I mean 128-bit types), I think sooner or later we
> > would do it anyway. For now we can just have a wrapper on top of number()
> > (yes, special_hex_number() probably too special for this case) to print it.
> > And yes, avoiding sprintf() in this case seems beneficial to me, we will have
> > one implementation of how we print pointers.
> 
> We followed this approach in a self contained manner inside core
> MM in order to avoid adding new printk format. TBH don't see too
> much value in again trying to create factored common code between
> with lib/vsprintf.c As David mentioned this may not be worth it.

I'm not fighting to death for this, just my observations, so we see
that majority of people agree with leaving this one independent on
lib/vsprintf.c implementation.

-- 
With Best Regards,
Andy Shevchenko