| 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:
<PN3PR01MB9597B87A165D8F9D76B41762B8CC2@PN3PR01MB9597.INDPRD01.PROD.OUTLOOK.COM>
Date: Fri, 28 Feb 2025 16:23:46 +0000
From: Aditya Garg <gargaditya08@...e.com>
To: Petr Mladek <pmladek@...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@...ts.linux.dev" <asahi@...ts.linux.dev>
Subject: Re: [PATCH v4] lib/vsprintf: Add support for generic FOURCCs by
extending %p4cc
> On 28 Feb 2025, at 9:29 PM, Petr Mladek <pmladek@...e.com> wrote:
>
> 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>
Definitely much clear.
>
>> +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.
I dunno what wrong, anyways I'll send a v5 so will make sure things go right.
>
>> ----
>>
>> 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.
I'll make that change
>
>> }
>>
>
> Otherwise, it looks good to me.
>
> Best Regards,
> Petr
Powered by blists - more mailing lists