From: Jani Nikula <jani.nikula@intel.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Jani Nikula <jani.nikula@intel.com>,
Markus Heiser <markus.heiser@darmarit.de>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Grant Likely <grant.likely@secretlab.ca>,
Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
Keith Packard <keithp@keithp.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-doc@vger.kernel.org, Hans Verkuil <hverkuil@xs4all.nl>
Subject: [docs-next PATCH 0/9] Documentation/sphinx follow-up
Date: Fri, 10 Jun 2016 17:16:54 +0300 [thread overview]
Message-ID: <cover.1465567017.git.jani.nikula@intel.com> (raw)
Hi Jon -
Thanks for merging the main Sphinx series! I greet you with another set
of patches on top. ;)
The main things here are reducing the noise on duplicate sections and
adding better support for extracting exported symbols when
EXPORT_SYMBOLs and kernel-doc are in separate files. And then there are
some drive-by cleanups and fixes on top.
I'm still working on rewriting Documentation/kernel-doc-nano-HOWTO.txt
to reflect all the changes, but didn't want to let these wait for that.
BR,
Jani.
PS. One wrinkle I spotted is that in the kernel-doc directive,
:functions: and :internal: also match structs and other types. This is
just kernel-doc the script shining its awesomeness through to the upper
layer; I just totally missed this earlier. I added :doc: to make the
distinction for documents, even though internally that uses kernel-doc
-function parameter as well.
Should we rename :functions: to, mmh, maybe :symbols: (for want of a
better word) while we still can, or leave that in as a historical
curiosity? I'm not sure there's much value in adding a separate :types:
(or something) for non-functions either? And should :internal: keep
returning non-functions as well? Or make that return just functions and
have another argument to get the types? Thoughts?
Jani Nikula (9):
kernel-doc: remove old debug cruft from dump_section()
kernel-doc: do not warn about duplicate default section names
kernel-doc: add missing semi-colons in option parsing
kernel-doc: abstract filename mapping
kernel-doc: add support for specifying extra files for EXPORT_SYMBOLs
kernel-doc: unify all EXPORT_SYMBOL scanning to one place
Documentation/sphinx: remove unnecessary temporary variable
Documentation/sphinx: use a more sensible string split in kernel-doc
extension
Documentation/sphinx: add support for specifying extra export files
Documentation/sphinx/kernel-doc.py | 18 +++++---
scripts/kernel-doc | 88 +++++++++++++++++++++++++++-----------
2 files changed, 75 insertions(+), 31 deletions(-)
--
2.1.4
next reply other threads:[~2016-06-10 14:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-10 14:16 Jani Nikula [this message]
2016-06-10 14:16 ` [docs-next PATCH 1/9] kernel-doc: remove old debug cruft from dump_section() Jani Nikula
2016-06-10 14:16 ` [docs-next PATCH 2/9] kernel-doc: do not warn about duplicate default section names Jani Nikula
2016-06-10 14:16 ` [docs-next PATCH 3/9] kernel-doc: add missing semi-colons in option parsing Jani Nikula
2016-06-10 14:16 ` [docs-next PATCH 4/9] kernel-doc: abstract filename mapping Jani Nikula
2016-06-10 14:16 ` [docs-next PATCH 5/9] kernel-doc: add support for specifying extra files for EXPORT_SYMBOLs Jani Nikula
2016-06-10 14:17 ` [docs-next PATCH 6/9] kernel-doc: unify all EXPORT_SYMBOL scanning to one place Jani Nikula
2016-06-10 14:17 ` [docs-next PATCH 7/9] Documentation/sphinx: remove unnecessary temporary variable Jani Nikula
2016-06-10 14:17 ` [docs-next PATCH 8/9] Documentation/sphinx: use a more sensible string split in kernel-doc extension Jani Nikula
2016-06-10 14:17 ` [docs-next PATCH 9/9] Documentation/sphinx: add support for specifying extra export files Jani Nikula
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=cover.1465567017.git.jani.nikula@intel.com \
--to=jani.nikula@intel.com \
--cc=corbet@lwn.net \
--cc=daniel.vetter@ffwll.ch \
--cc=grant.likely@secretlab.ca \
--cc=hverkuil@xs4all.nl \
--cc=keithp@keithp.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markus.heiser@darmarit.de \
--cc=mchehab@osg.samsung.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 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.