From: "Ricardo Cañuelo" <ricardo.canuelo@collabora.com>
To: Petr Mladek <pmladek@suse.com>
Cc: linux-doc@vger.kernel.org, corbet@lwn.net, kernel@collabora.com,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH] docs: printk-basics: update the pr_debug() kerneldoc
Date: Wed, 20 May 2020 09:22:45 +0200 [thread overview]
Message-ID: <8ec034340546a0548ff4a0d63ccf335a19358e66.camel@collabora.com> (raw)
In-Reply-To: <20200519131558.GM7340@linux-b0ei>
Hi Petr, thanks for taking the time to review this
On Tue, 2020-05-19 at 15:15 +0200, Petr Mladek wrote:
> It is pity that you did not add other printk maintainers into CC for
> the patches adding this documentation and comments. I was sick
> last two months and was not able to check mails.
I'm sorry for that and I hope you're better now.
> Adding them now. Note that the following patch is already in
> linux-next, see
> https://lore.kernel.org/r/20200403093617.18003-1-ricardo.canuelo@collabora.com
Indeed, I mentioned that in the patch. Maybe I should've been clearer in the
background description.
> Well, I have mixed feelings about this type of documentation. It might explain
> some things that are less obvious, for example, the meaning of
> pr_fmt(). On the other hand:
>
> + It might be complicated to keep it in sync.
>
> + I wonder how many developers would actually read it.
>
> + The doc comments in include/linux/prinkt.h are really
> long and describe obvious things.
>
> By other words. These comments make the headers and sources hard to
> read. And at least in this particular case, the gain is questionable.
Well, I think that some things may not be too obvious for beginners and that
documenting them explicitly is a positive thing overall. I don't think this kind
of comments (comment blocks before a function prototype, not interleaved in the
code) pollute the code or make it harder to read, but that's a personal opinion,
I guess.
I agree that this might introduce a maintainance overhead when it comes to
sync'ing the code and the documentation but, on the other hand, printk.h isn't
something that changes too frequently, is it?
Best regards,
Ricardo
prev parent reply other threads:[~2020-05-20 7:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-22 14:03 [PATCH] docs: printk-basics: update the pr_debug() kerneldoc Ricardo Cañuelo
2020-05-19 13:15 ` Petr Mladek
2020-05-20 7:22 ` Ricardo Cañuelo [this message]
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=8ec034340546a0548ff4a0d63ccf335a19358e66.camel@collabora.com \
--to=ricardo.canuelo@collabora.com \
--cc=corbet@lwn.net \
--cc=kernel@collabora.com \
--cc=linux-doc@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).