From: Jonathan Corbet <corbet@lwn.net>
To: Jani Nikula <jani.nikula@intel.com>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Keith Packard <keithp@keithp.com>
Subject: Re: [RFC] A first shot at asciidoc-based formatted docs
Date: Tue, 9 Feb 2016 17:09:38 -0700 [thread overview]
Message-ID: <20160209170938.3a4b9fb1@lwn.net> (raw)
In-Reply-To: <cover.1453809420.git.jani.nikula@intel.com>
On Tue, 26 Jan 2016 14:08:45 +0200
Jani Nikula <jani.nikula@intel.com> wrote:
> I'm afraid we've done some overlapping work in the mean time, but I'm
> happy we've both looked at the tool chain, and can have a more
> meaningful conversation now.
[Adding Keith since you said you wanted to be a part of this - let us know
when you've had enough!]
So I've spent a bit of time looking at this, and quite a bit more time
talking with various folks at LCA. There is pretty much universal
agreement that this is interesting work and the direction we'd like to
go. My current hope is that we can merge some version of it for 4.6 and
see where it goes from there.
So naturally I have some thoughts on the whole thing...
- I would like to format directly to HTML if at all possible. It seems
it should be possible to get a table of contents into the files, and
the feedback I got was that a TOC would be enough for navigation - it
would not be necessary to split the files at that point. We might
still want to try to figure that out too, though. In any case, this
isn't a show stopper, in that we can change it anytime if a better way
shows up. But I'd like to have it in mind.
- Asciidoc templates and processing should happen in a new directory
(perhaps imaginatively called "asciidoc"); having them in a directory
called "DocBook" seems a little weird. More importantly, though, I'd
like to separate them out as a fresh start, and not mess with the
existing DocBook templates until we decide we don't need them anymore.
If we could end up with a cleaner, simpler makefile in the process,
that would be a bonus.
- I'm not sold on the new inclusion mechanism. Creating thousands of
little files and tracking them for dependencies and such doesn't seem
like a simplification or a path toward better performance. I would
like to at least consider keeping the direct-from-source inclusion.
- Insisting on EXPORT_SYMBOL being in the same file doesn't seem like
it's going to work for now; that could maybe change after Al's work
goes in, which could be fairly soon.
Please let me know your thoughts on the above. Do you think you can find
some time over the next month for this? I'll try to shake loose some time
too, but, well, $EXCUSES...
Many thanks for doing this work!
jon
next prev parent reply other threads:[~2016-02-10 0:09 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 23:28 Jonathan Corbet
2016-01-25 23:28 ` [PATCH 1/4] kernel-doc: add support for asciidoc output Jonathan Corbet
2016-01-25 23:28 ` [PATCH 2/4] docproc: handle asciidoc templates Jonathan Corbet
2016-01-25 23:28 ` [PATCH 3/4] Docs: Makefile tweaks for " Jonathan Corbet
2016-01-25 23:28 ` [PATCH 4/4] Docs: add a sample asciidoc template Jonathan Corbet
2016-01-26 12:08 ` [RFC] A first shot at asciidoc-based formatted docs Jani Nikula
2016-01-26 12:08 ` [RFC 01/10] kernel-doc: rewrite usage description, remove duplicated comments Jani Nikula
2016-01-26 12:08 ` [RFC 02/10] kernel-doc: add support for asciidoc output Jani Nikula
2016-01-26 12:08 ` [RFC 03/10] kernel-doc: support printing exported and non-exported symbols Jani Nikula
2016-01-26 12:08 ` [RFC 04/10] kernel-doc: add support for printing DOC: comments with escaped names Jani Nikula
2016-01-26 12:08 ` [RFC 05/10] scripts: add asciidoc-includes to extract includes from asciidoc Jani Nikula
2016-01-26 12:08 ` [RFC 06/10] scripts: add a kernel-doc helper for special invocation Jani Nikula
2016-01-26 12:08 ` [RFC 07/10] scripts: add tool for generating asciidoc dependencies and rules Jani Nikula
2016-01-26 12:08 ` [RFC 08/10] scripts: add a crude converter from DocBook tmpl to asciidoc Jani Nikula
2016-01-26 12:08 ` [RFC 09/10] Documentation: convert gpu.tmpl to gpu.txt Jani Nikula
2016-01-26 12:08 ` [RFC 10/10] Documentation: build asciidoc documentation Jani Nikula
2016-01-26 12:17 ` [RFC] A first shot at asciidoc-based formatted docs Daniel Vetter
2016-01-26 12:38 ` Jani Nikula
2016-01-26 14:48 ` Jonathan Corbet
2016-01-26 14:52 ` Jonathan Corbet
2016-02-10 0:09 ` Jonathan Corbet [this message]
2016-02-10 8:07 ` Daniel Vetter
2016-02-10 14:03 ` Jani Nikula
2016-02-10 16:12 ` Jani Nikula
2016-02-10 20:56 ` Jonathan Corbet
2016-02-11 15:18 ` Keith Packard
2016-02-10 20:45 ` Jonathan Corbet
2016-02-10 23:01 ` Keith Packard
2016-02-11 13:44 ` Jani Nikula
2016-02-11 15:21 ` Keith Packard
2016-02-13 3:20 ` Keith Packard
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=20160209170938.3a4b9fb1@lwn.net \
--to=corbet@lwn.net \
--cc=daniel.vetter@ffwll.ch \
--cc=jani.nikula@intel.com \
--cc=keithp@keithp.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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
Powered by JetHome