Re: [PATCH] doc: convert printk-formats.txt to rst
From: Kees Cook
Date: Fri Dec 08 2017 - 16:06:55 EST
On Thu, Dec 7, 2017 at 4:46 PM, Tobin C. Harding <me@xxxxxxxx> wrote:
> On Thu, Dec 07, 2017 at 04:19:56PM -0800, Kees Cook wrote:
>> On Thu, Dec 7, 2017 at 3:44 PM, Tobin C. Harding <me@xxxxxxxx> wrote:
>> > Cheers Kees. FTR, changes to implement are:
>> >
>> > - Fix the capitalization of 'kernel'.
>>
>> I don't really have an opinion about which way is right. I personally
>> don't capitalize it unless I speak about it as a single thing "The
>> Linux Kernel". In this case I just noticed you had mixed usage.
>>
>> > - Add ESCAPE_* flags back into kernel-docs in lib/vsprintf.c
>>
>> I actually meant each of the sections. Several of the formats have
>> per-item breakdowns that went missing in the new kernel-doc (ESCAPE_*
>> was just an example).
>
> Oh dear, you don't like that. This is actually the part of the patch
> that I was least sure about doing. I'm happy to revert, can I give you
> my thought process for comment?
>
> When the kernel-docs get included into printk-formats.rst it seems
> overly verbose to have all the information given twice. And then it
> seems odd to bother having the extra descriptions in printk-formats.rst
> if _all_ the required information is already in the kernel-docs?
>
> So I guessed that it would be nice for devs to get a bit of a hint at
> the specifiers when having lib/vsprintf.c open (and they have the code
> too) then if they needed more information going to printk-formats.rst.
>
> Also, since there is more space in printk-fomats.rst the info can be
> spaced better and easier to read.
>
> Your thoughts?
Well ... my sense is that lib/vsprintf.c should remain the canonical
documentation. Anyone working on the code has the docs all together in
one file. If it helps the .rst file to reformat the comments into
kernel-doc, that's fine, but it shouldn't reduce the detail that is
present, IMO. Now, expanding on it in printk-formats.rst is certainly
a great idea, but I don't think it should come at the expense of
someone just reading through vsprintf.c. That said, I can certainly
see that redundancy is annoying, and it's possible for
printk-formats.rst and vsprintf.c get get out of sync, but that
doesn't seem to be a new problem.
I'd be curious to see what Jon or Joe think about this.
(Perhaps the best first step would be to leave vsprintf.c as-is
without kernel-doc-ification?)
-Kees
--
Kees Cook
Pixel Security