All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tobin C. Harding" <me@tobin.cc>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Randy Dunlap <rdunlap@infradead.org>,
	Andrew Murray <amurray@mpc-data.co.uk>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] doc: convert printk-formats.txt to rst
Date: Thu, 7 Dec 2017 08:30:13 +1100	[thread overview]
Message-ID: <20171206213013.GE11835@eros> (raw)
In-Reply-To: <20171206112325.1a76727b@lwn.net>

On Wed, Dec 06, 2017 at 11:23:25AM -0700, Jonathan Corbet wrote:
> On Wed,  6 Dec 2017 12:45:29 +1100
> "Tobin C. Harding" <me@tobin.cc> wrote:
> 
> > Documentation/printk-formats.txt is a candidate for conversion to
> > ReStructuredText format. Some effort has already been made to do this
> > conversion even thought the suffix is currently .txt
> > 
> > Changes required to complete conversion
> > 
> > - Add double backticks where needed.
> > - Add entry to Documentation/index.rst
> > - Use flat-table instead of ASCII table.
> > - Fix minor grammatical errors.
> > - Capitalize headers and correctly order heading adornments.
> > - Use 'Passed by reference' uniformly.
> > - Update pointer documentation around %px specifier.
> > - Fix erroneous double backticks (to commas).
> > - Simplify documentation for kobject.
> > - Convert lib/vsnprintf.c function docs to use kernel-docs and
> >   include in Documentation/printk-formats.rst
> > 
> > Signed-off-by: Tobin C. Harding <me@tobin.cc>
> 
> Some comments from a quick review:
> 
>  - I would just put this into the core-api manual; we don't need to create
>    a separate section for printk formats.

Cool, I was hoping you'd give some direction on this. thanks.

>  - I agree with Markus and others about the table.  I think I would go a
>    little further and encourage observance of the "use minimal markup"
>    rule.  Lots of ``double backticks`` make for slightly nicer HTML/PDF
>    output, but they come at the expense of plain-text readability, which
>    is something we really don't want to sacrifice.

Great. I personally don't read docs in HTML/PDF so I like this ruling.

>  - The vsprintf.c part is probably not for me to take, so it should be
>    split out into a separate patch.

I'm much less experienced than you Jon so please say if I am wrong but
since the rst file depends on the changes to vsprintf.c wouldn't it be
better if the changes went into the mainline together. I can split it
into a two patch set if that is cleaner but putting the two patches
through different trees seems like a bad idea because of the
dependency. For what it's worth, I don't believe lib/vsprintf.c has a
maintainer. Linus took changes to that file from my tree just
recently. I don't know how this stuff works though in regards to merge
conflicts. (Please take everything I say here with a pinch of salt since
I have only maintained a tree for a few weeks now.)

thanks,
Tobin.

  reply	other threads:[~2017-12-06 21:30 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-06  1:45 [PATCH] doc: convert printk-formats.txt to rst Tobin C. Harding
2017-12-06  7:11 ` Markus Heiser
2017-12-06  7:35   ` Joe Perches
2017-12-06 17:55     ` Randy Dunlap
2017-12-06 18:18 ` Randy Dunlap
2017-12-06 21:16   ` Tobin C. Harding
2017-12-07  0:39     ` Randy Dunlap
2017-12-07  5:25       ` Tobin C. Harding
2017-12-06 22:11   ` Tobin C. Harding
2017-12-06 18:23 ` Jonathan Corbet
2017-12-06 21:30   ` Tobin C. Harding [this message]
2017-12-07 22:50 ` Kees Cook
2017-12-07 23:01   ` Jonathan Corbet
2017-12-07 23:50     ` Tobin C. Harding
2017-12-07 23:44   ` Tobin C. Harding
2017-12-08  0:19     ` Kees Cook
2017-12-08  0:46       ` Tobin C. Harding
2017-12-08 21:06         ` Kees Cook
2017-12-08 21:22           ` Joe Perches
2017-12-09  1:27             ` Tobin C. Harding
2017-12-09  2:18               ` Joe Perches
2017-12-09  6:33                 ` Tobin C. Harding
2017-12-11 18:40                   ` Laura Abbott
2017-12-09 11:48                 ` Dan Carpenter
2017-12-11  0:51                   ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171206213013.GE11835@eros \
    --to=me@tobin.cc \
    --cc=amurray@mpc-data.co.uk \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.