From: Alexey Dobriyan <adobriyan@gmail.com>
To: "Peter Hüwe" <PeterHuewe@gmx.de>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [CORE-TOPIC] Documentation
Date: Mon, 13 Jul 2015 12:47:23 +0300 [thread overview]
Message-ID: <CACVxJT9WjwWZUQWPk_jXOLOZsTh8HdGuKWr1ri3q02fEaFLejA@mail.gmail.com> (raw)
In-Reply-To: <201507130038.01474.PeterHuewe@gmx.de>
On Mon, Jul 13, 2015 at 1:38 AM, Peter Hüwe <PeterHuewe@gmx.de> wrote:
> as we talked about recruiting in the other thread I realized that one thing
> that might reduce the entrance barrier a bit (apart from tooling and flow)
> would be proper documentation.
Newbies should not write documentation because they, by definition,
have little knowledge of the code. It will lead to many, many useless
and redundant comments like below whose only purpose is stealing
vertical whitespace:
/**
* is_module_percpu_address - test whether address is from module
static percpu
* @addr: address to test
*
* Test whether @addr belongs to module static percpu area.
*
* RETURNS:
* %true if @addr is from module static percpu area
*/
bool is_module_percpu_address(unsigned long addr)
{
I have counter suggestion:
* remove kernel-doc official status, remove generating scripts
because it doesn't work,
* trim redundant and semi-redundant kernel-doc comments like this:
/**
* module_refcount - return the refcount or -1 if unloading
*
* @mod: the module we're checking
*
* Returns:
* -1 if the module is in the process of unloading
* otherwise the number of references in the kernel to the module
*/
int module_refcount(struct module *mod)
{
("return reference count or -1 if module is being unloaded" is enough here).
Alexey
next prev parent reply other threads:[~2015-07-13 9:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-12 22:38 Peter Hüwe
2015-07-12 23:15 ` Julia Lawall
2015-07-14 11:59 ` Mauro Carvalho Chehab
2015-07-13 9:47 ` Alexey Dobriyan [this message]
2015-07-13 16:01 ` Randy Dunlap
2015-07-13 16:37 ` Steven Rostedt
2015-07-13 16:46 ` David Woodhouse
2015-07-13 17:35 ` Steven Rostedt
2015-07-13 19:22 ` Peter Hüwe
2015-07-13 19:28 ` Peter Hüwe
2015-07-13 17:42 ` Jason Cooper
2015-07-13 18:11 ` Steven Rostedt
2015-07-14 3:56 ` Zefan Li
2015-07-13 19:25 ` Peter Hüwe
2015-07-13 22:10 ` Laurent Pinchart
2015-07-13 17:45 ` Jonathan Corbet
2015-07-13 19:46 ` Peter Hüwe
2015-07-14 2:36 ` Jonathan Corbet
2015-07-14 8:40 ` Laurent Pinchart
2015-07-14 11:19 ` Daniel Vetter
2015-07-14 12:43 ` Mauro Carvalho Chehab
2015-07-14 12:53 ` Jonathan Corbet
2015-07-14 13:57 ` Laurent Pinchart
2015-07-14 6:44 ` Johannes Berg
2015-07-13 19:20 ` Peter Hüwe
2015-07-13 23:01 ` Laurent Pinchart
2015-07-13 17:05 ` Lai Jiangshan
2015-07-13 17:42 ` Jonathan Corbet
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=CACVxJT9WjwWZUQWPk_jXOLOZsTh8HdGuKWr1ri3q02fEaFLejA@mail.gmail.com \
--to=adobriyan@gmail.com \
--cc=PeterHuewe@gmx.de \
--cc=dan.carpenter@oracle.com \
--cc=ksummit-discuss@lists.linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox