From: Johannes Berg <johannes@sipsolutions.net>
To: Markus Heiser <markus.heiser@darmarit.de>
Cc: linux-wireless@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH 1/2] Documentation/sphinx: kerneldoc: add "unused-functions"
Date: Fri, 31 Mar 2017 10:42:08 +0200 [thread overview]
Message-ID: <1490949728.6288.3.camel@sipsolutions.net> (raw)
In-Reply-To: <8F272073-79D4-4721-B481-ED018A58174F@darmarit.de>
> Do we really need such generic stuff? ... IMO explicit is better than
> implicit. Why not getting an error when a function, which is referred
> from a reST-document disappears in the source? Those errors help
> to maintain the consistency of documentation with source-code.
That's a totally different problem.
> I know, there are also use-cases where generic is very helpful (e.g.
> create a complete API description from the header file, with just
> one line in reST). And I know, that we have already generic e.g. the
> "export" option of the kernel-doc directive.
Exactly. But now you can either
* use "export" or "internal" to get *everything*
* list every single function, and get no warning when there's a
function you didn't list
This serves to help get a mixture of the two, to be able to group
things but also document everything that got missed as a fall-back.
johannes
next prev parent reply other threads:[~2017-03-31 8:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-31 7:16 [PATCH 1/2] Documentation/sphinx: kerneldoc: add "unused-functions" Johannes Berg
2017-03-31 7:16 ` [PATCH 2/2] cfg80211: add remaining functions/etc. to documentation Johannes Berg
2017-03-31 8:39 ` [PATCH 1/2] Documentation/sphinx: kerneldoc: add "unused-functions" Markus Heiser
2017-03-31 8:42 ` Johannes Berg [this message]
2017-03-31 12:54 ` Jani Nikula
2017-04-03 19:59 ` Johannes Berg
2017-04-04 7:26 ` Jani Nikula
2017-05-30 13:23 ` Johannes Berg
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=1490949728.6288.3.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=markus.heiser@darmarit.de \
/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.