Re: [PATCH 2/4] coding-style: show how reusing macros prevents naming collisions

2024-01-08 Thread Jonathan Corbet
Yueh-Shun Li writes: >> So everything we add to our documentation has a cost in terms of reader >> attention. We ask people to read through a lot of material now, and >> should only increase that ask for good reason. >> >> With that context, I have to wonder whether we really need to tell our >

Re: [PATCH 2/4] coding-style: show how reusing macros prevents naming collisions

2024-01-08 Thread Yueh-Shun Li
Dear Mr. Corbet, Thank you very much for your feed back. On 2024-01-09 00:28, Jonathan Corbet wrote: Yueh-Shun Li writes: In section "18) Don't re-invent the kernel macros" in "Linux kernel coding style": Show how reusing macros from shared headers prevents naming collisions using "stringif

Re: [PATCH 2/4] coding-style: show how reusing macros prevents naming collisions

2024-01-08 Thread Jonathan Corbet
Yueh-Shun Li writes: > In section "18) Don't re-invent the kernel macros" in "Linux kernel > coding style": > > Show how reusing macros from shared headers prevents naming collisions > using "stringify", the one of the most widely reinvented macro, as an > example. > > This patch aims to provide

[PATCH 2/4] coding-style: show how reusing macros prevents naming collisions

2024-01-08 Thread Yueh-Shun Li
In section "18) Don't re-invent the kernel macros" in "Linux kernel coding style": Show how reusing macros from shared headers prevents naming collisions using "stringify", the one of the most widely reinvented macro, as an example. This patch aims to provide a stronger reason to reuse shared mac