lkml.org 
[lkml]   [2017]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] doc: convert printk-formats.txt to rst
On Thu, Dec 7, 2017 at 4:46 PM, Tobin C. Harding <me@tobin.cc> 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@tobin.cc> 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

\
 
 \ /
  Last update: 2017-12-08 22:07    [W:0.063 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site