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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html