Re: [RFC 1/2] lib/vsprintf: Add support for pte_t

[Petr Mladek <pmladek@suse.com>]

On Fri 2025-06-20 13:32:31, Anshuman Khandual wrote:
> On 19/06/25 7:31 PM, Petr Mladek wrote:
> > On Wed 2025-06-18 09:42:34, Anshuman Khandual wrote:
> >> Add a new format for printing page table entries.
> > 
> > How many users do you explect, please?
> > 
> > This patch adds only one caller. It does not justify the added complexity.
> 
> Understood.
> 
> The idea is to convert all page table entry prints through out the tree
> both in generic and platform code. Added just a single generic example
> here for this being a RFC proposal. Will go through similar instances
> and be back with more comprehensive change set.

You do not need to cover all cases at this stage. For me it is enough
to know that the printf format will have several (like >= 5) users.

> >> @@ -2542,6 +2545,23 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
[...]
> Agreed. Andy also might have suggested about special_hex_number() helper
> on the other thread. Will try and use the helper instead.
> 
> > 
> >> +			spec.base = 16;
> >> +			spec.flags = SPECIAL | SMALL | ZEROPAD;
> >> +			if (sizeof(pte_t) == sizeof(u64)) {
> >> +				u64 val = pte_val(*pte);
> >> +
> >> +				return number(buf, end, val, spec);
> >> +			}
> >> +			WARN_ONCE(1, "Non standard pte_t\n");
> > 
> > This is nasty. It should be a compile-time check. And the code should
> 
> Something like BUILD_BUG_ON() against pte_t as either u64 or u32 aka all
> the sizes the print format is going to support and it should pass on all
> platforms ?

Yes, I had BUILD_BUG_ON() in mind. It would be nice if you check at
least the most known architectures. You could do it just by looking
into the code. We could rely on the bots, monitoring mailing list
and linux-next, for the less known architectures.

The more you check in advance the less surprises would come
from the bots.

Best Regards,
Petr