From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 48344408028 for ; Thu, 9 Jul 2026 11:12:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783595559; cv=none; b=BkNs6iP37aA43IdtuzaMmJcBLgmgpoce+mC1XIXOoBSHvuE4fdfE4uDZwFoIA5cJr74EiaClYWr9mf3q1dIGVQtkeydLBc5Ld+6X6/P/jh/9mkIzlYN/rDe2178UJLYAYPX2xxZAjY+gENzZ8RaRbu5lOgKTpcywRRJap1O3DCo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783595559; c=relaxed/simple; bh=ndofg+FHLcXbaZ+NoLuggN/AiIw9lURC3R2d0e+fzXo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=W0p4joiDAnjNDDOGJqdozK0iBva9ubhJxXIaZfaID4vRARITQ+B0kAvTgVRud80228pxCU6ELNgH7D9dFfE3Kdt+zBFr9Sd7eCpjUeW8NCRT+9+iagQR50FDB8WnMDWRmAcfubff0QOcEXAoZAWGKfOItytbReox8FswDY+u0xk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=Np88rsgt; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="Np88rsgt" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E401F3570; Thu, 9 Jul 2026 04:12:31 -0700 (PDT) Received: from [10.174.42.219] (unknown [10.174.42.219]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6BBCE3FE53; Thu, 9 Jul 2026 04:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1783595556; bh=ndofg+FHLcXbaZ+NoLuggN/AiIw9lURC3R2d0e+fzXo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Np88rsgtZjjopyeDlMeens7x/4+xIy3dlsldVZrnslOla0EFQrIdqzer0er2ZpCxy qecOd4mhhC9oCH0LbVsC+DYpYsWmr1XC6OtUM2RwlBToMkqYm4xcM8rfVjYjPXhE7t QTJZQEKinNzJUQA39rDJ6+h9rFVAndDZ5KGhxnYY= Message-ID: Date: Thu, 9 Jul 2026 16:42:30 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V3] mm: Standardize printing for pgtable entries To: Andy Shevchenko , "David Hildenbrand (Arm)" Cc: Petr Mladek , linux-mm@kvack.org, usama.arif@linux.dev, hughd@google.com, willy@infradead.org, ryan.roberts@arm.com, Andrew Morton , linux-kernel@vger.kernel.org References: <20260709044334.1741263-1-anshuman.khandual@arm.com> Content-Language: en-US From: Anshuman Khandual In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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.