| 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
| ||
|
Message-ID: <Z8HdVfr2hWyzhwHh@pathway.suse.cz>
Date: Fri, 28 Feb 2025 16:59:17 +0100
From: Petr Mladek <pmladek@...e.com>
To: Aditya Garg <gargaditya08@...e.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
"andriy.shevchenko@...ux.intel.com" <andriy.shevchenko@...ux.intel.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
"senozhatsky@...omium.org" <senozhatsky@...omium.org>,
"corbet@....net" <corbet@....net>,
"akpm@...ux-foundation.org" <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-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Hector Martin <marcan@...can.st>,
"sven@...npeter.dev" <sven@...npeter.dev>,
Janne Grunau <j@...nau.net>,
"alyssa@...enzweig.io" <alyssa@...enzweig.io>,
Asahi Linux Mailing List <asahi@...ts.linux.dev>
Subject: Re: [PATCH v4] lib/vsprintf: Add support for generic FOURCCs by
extending %p4cc
On Thu 2025-02-27 06:30:48, Aditya Garg wrote:
> From: Hector Martin <marcan@...can.st>
>
> %p4cc is designed for DRM/V4L2 FOURCCs with their specific quirks, but
> it's useful to be able to print generic 4-character codes formatted as
> an integer. Extend it to add format specifiers for printing generic
> 32-bit FOURCCs with various endian semantics:
>
> %p4ch Host-endian
> %p4cl Little-endian
> %p4cb Big-endian
> %p4cr Reverse-endian
>
> The endianness determines how bytes are interpreted as a u32, and the
> FOURCC is then always printed MSByte-first (this is the opposite of
> V4L/DRM FOURCCs). This covers most practical cases, e.g. %p4cr would
> allow printing LSByte-first FOURCCs stored in host endian order
> (other than the hex form being in character order, not the integer
> value).
>
> Signed-off-by: Hector Martin <marcan@...can.st>
> Signed-off-by: Aditya Garg <gargaditya08@...e.com>
>
> --- a/Documentation/core-api/printk-formats.rst
> +++ b/Documentation/core-api/printk-formats.rst
> @@ -648,6 +648,38 @@ Examples::
> %p4cc Y10 little-endian (0x20303159)
> %p4cc NV12 big-endian (0xb231564e)
>
> +Generic FourCC code
> +-------------------
> +
> +::
> + %p4c[hrbl] gP00 (0x67503030)
> +
> +Print a generic FourCC code, as both ASCII characters and its numerical
> +value as hexadecimal.
> +
> +The additional ``h``, ``r``, ``b``, and ``l`` specifiers are used to specify
> +host, reversed, big or little endian order data respectively. Host endian
> +order means the data is interpreted as a 32-bit integer and the most
> +significant byte is printed first; that is, the character code as printed
> +matches the byte order stored in memory on big-endian systems, and is reversed
> +on little-endian systems.
I am a bit confused by the description like I was in the past, see
https://lore.kernel.org/r/Y3zhhLoqAOaZ7rMz@alley ;-)
I wonder if the following sounds better:
<proposa>
Print a generic FourCC code, as both ASCII characters and its numerical
value as hexadecimal.
The generic FourCC code is always printed in the the big-endian format,
the most significant byte first. This is the opposite of V4L/DRM
FOURCCs.
The additional ``h``, ``r``, ``b``, and ``l`` specifiers define what
endianes is used to load the stored bytes. The data might be interpreted
using the host-endian, reverse-host-endian, big-endian, or little endian.
</proposal>
> +Passed by reference.
> +
> +Examples for a little-endian machine, given &(u32)0x67503030::
> +
> + %p4ch gP00 (0x67503030)
> + %p4cr 00Pg (0x30305067)
> + %p4cb 00Pg (0x30305067)
> + %p4cl gP00 (0x67503030)
> +
> +Examples for a big-endian machine, given &(u32)0x67503030::
> +
> + %p4ch gP00 (0x67503030)
> + %p4cr 00Pg (0x30305067)
> + %p4cb gP00 (0x67503030)
> + %p4cl 00Pg (0x30305067)
> +
> Rust
The patch has been malformed. I guess that your mail client
removed spaces at the beginning of some lines.
> ----
>
> diff --git a/lib/test_printf.c b/lib/test_printf.c
> index 59dbe4f9a..056929c06 100644
> --- a/lib/test_printf.c
> +++ b/lib/test_printf.c
> @@ -776,21 +776,46 @@ static void __init fwnode_pointer(void)
> software_node_unregister_node_group(group);
> }
>
> +struct fourcc_struct {
> + u32 code;
> + const char *str;
> +};
> +
> +static void __init fourcc_pointer_test(const struct fourcc_struct *fc, size_t n,
> + const char *fmt)
> +{
> + size_t i;
> +
> + for (i = 0; i < n; i++)
> + test(fc[i].str, fmt, &fc[i].code);
> +}
> +
> static void __init fourcc_pointer(void)
> {
> - struct {
> - u32 code;
> - char *str;
> - } const try[] = {
> + static const struct fourcc_struct try_cc[] = {
> { 0x3231564e, "NV12 little-endian (0x3231564e)", },
> { 0xb231564e, "NV12 big-endian (0xb231564e)", },
> { 0x10111213, ".... little-endian (0x10111213)", },
> { 0x20303159, "Y10 little-endian (0x20303159)", },
> };
> - unsigned int i;
> + static const struct fourcc_struct try_ch = {
> + 0x41424344, "ABCD (0x41424344)",
> + };
> + static const struct fourcc_struct try_cr = {
> + 0x41424344, "DCBA (0x44434241)",
> + };
> + static const struct fourcc_struct try_cl = {
> + le32_to_cpu(0x41424344), "ABCD (0x41424344)",
> + };
> + static const struct fourcc_struct try_cb = {
> + be32_to_cpu(0x41424344), "ABCD (0x41424344)",
> + };
>
> - for (i = 0; i < ARRAY_SIZE(try); i++)
> - test(try[i].str, "%p4cc", &try[i].code);
> + fourcc_pointer_test(try_cc, ARRAY_SIZE(try_cc), "%p4cc");
> + fourcc_pointer_test(&try_ch, 1, "%p4ch");
> + fourcc_pointer_test(&try_cr, 1, "%p4cr");
> + fourcc_pointer_test(&try_cl, 1, "%p4cl");
> + fourcc_pointer_test(&try_cb, 1, "%p4cb");
Nit: I would use ARRAY_SIZE() instead of the hardcoded 1 in all cases.
But it might be a matter of taste.
> }
>
Otherwise, it looks good to me.
Best Regards,
Petr
Powered by blists - more mailing lists