linux-kernel - Re: [PATCH 2/2] drm/appletbdm: use %p4cl instead of %p4cc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z9Gfj_f0Ug7vLIfd@smile.fi.intel.com>
Date: Wed, 12 Mar 2025 16:51:59 +0200
From: "andriy.shevchenko@...ux.intel.com" <andriy.shevchenko@...ux.intel.com>
To: Thomas Zimmermann <tzimmermann@...e.de>
Cc: Aditya Garg <gargaditya08@...e.com>, Aun-Ali Zaidi <admin@...eit.net>,
	Maxime Ripard <mripard@...nel.org>,
	"airlied@...hat.com" <airlied@...hat.com>,
	Simona Vetter <simona@...ll.ch>, Petr Mladek <pmladek@...e.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	"senozhatsky@...omium.org" <senozhatsky@...omium.org>,
	Jonathan Corbet <corbet@....net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"apw@...onical.com" <apw@...onical.com>,
	"joe@...ches.com" <joe@...ches.com>,
	"dwaipayanray1@...il.com" <dwaipayanray1@...il.com>,
	"lukas.bulwahn@...il.com" <lukas.bulwahn@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Hector Martin <marcan@...can.st>, Sven Peter <sven@...npeter.dev>,
	Asahi Linux Mailing List <asahi@...ts.linux.dev>
Subject: Re: [PATCH 2/2] drm/appletbdm: use %p4cl instead of %p4cc

On Wed, Mar 12, 2025 at 12:51:33PM +0100, Thomas Zimmermann wrote:
> Am 12.03.25 um 10:06 schrieb Aditya Garg:

...

> If you want to print out protocol-header tokens, why not use formatting
> macros as we do with DRM mode? There's one for the format string [1] and one
> for the argument. [2] It's not as fancy as the conversion code, but you'll
> get something for your driver that is easily understandable.

The benefit of the specific code formatters as in this patch at least in the
stack usage and hence a lot of code generated again and again. I believe you
can get rid of dozens of (kilo?) bytes in DRM on top of compensating this in
the printf() implementation. This backs us to the discussion on how the best
would be to implement custom printf() specifiers...

-- 
With Best Regards,
Andy Shevchenko