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

[Anshuman Khandual <anshuman.khandual@arm.com>]

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.