From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Lars Kurth <lars.kurth@citrix.com>,
Lars Kurth <lars.kurth.xen@gmail.com>
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>,
"Tim (Xen.org)" <tim@xen.org>,
Xen-devel <xen-devel@lists.xen.org>,
Jim Fehlig <jfehlig@suse.com>, Jan Beulich <JBeulich@suse.com>,
Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [RFC v2 for-4.6 0/2] In-tree feature documentation
Date: Fri, 28 Aug 2015 20:06:24 +0100 [thread overview]
Message-ID: <55E0B130.4050708@citrix.com> (raw)
In-Reply-To: <D2066A8A.20433%lars.kurth@citrix.com>
On 28/08/15 19:52, Lars Kurth wrote:
>
> On 28/08/2015 19:18, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>
>> On 28/08/15 18:51, Lars Kurth wrote:
>>> We may need some extra tags/headings, if we were to include things such
>>> as supported limits for memory, vCPUs, ... I remember, you raised the
>>> point that some of the theoretical limits are not always tested.
>> Absolutely. Not everyone has a server with 123TB of RAM to hand, or
>> even 16TB which is default current limit. (For this issue, testing from
>> both Citrix and Oracle indicates a bug when more than 5TB of RAM is used.)
>>
>> Therefore, a distinction between the theoretical limit and
>> currently-tested limit is very useful. I expect the the commercial
>> stakeholders will be in a position to routinely test at far above the
>> limit available to direct consumers of the Xen project.
>>
>> For the in-tree statement of limits, I have not put much though to how
>> to represent them yet, but I am not sure that the feature template
>> proposed in #1 will be a great fit. I suspect we will want something a
>> little different.
> Maybe a master document for system stuff, with a slightly different format.
Possibly. Nothing prevents us from having different types of
documentation with different expected layouts.
We can see what feels best when we get to it.
>
> I may have missed this: what kind of mark-up is being used?
> http://pandoc.org/ seems to support a few: may need to add a README with a
> couple of pointers.
http://pandoc.org/demo/example9/pandocs-markdown.html
Pandoc extends plain markdown in a number of ways commonly found
elsewhere, including the ability to insert raw LaTeX if needs be.
The eagle-eyed might have spotted a cunningly positioned \clearpage
which aids the clarity of the generated pdf file.
>
> And I am assuming some sort of index is produced when these docs are
> built: correct?
For the HTML ones, yes. One example is:
http://xenbits.xen.org/docs/unstable/specs/libxc-migration-stream.html
Which is currently generated from a pandoc document in tree.
By default in-tree, all pandoc stuff will be rendered to pdf and html.
I am not aware whether the pdf versions are served from xenbits, but the
html ones certainly are.
~Andrew
prev parent reply other threads:[~2015-08-28 19:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-25 10:40 [RFC v2 for-4.6 0/2] In-tree feature documentation Andrew Cooper
2015-08-25 10:40 ` [PATCH v2 for-4.6 1/2] docs: Template for feature documents Andrew Cooper
2015-09-01 13:41 ` Ian Campbell
2015-09-01 13:45 ` Andrew Cooper
2015-08-25 10:40 ` [PATCH v2 for-4.6 2/2] docs: Migration feature document Andrew Cooper
2015-08-27 2:15 ` Jim Fehlig
2015-08-27 10:35 ` Andrew Cooper
2015-08-27 2:44 ` [RFC v2 for-4.6 0/2] In-tree feature documentation Jim Fehlig
2015-08-27 10:46 ` Andrew Cooper
2015-08-27 14:52 ` Ian Jackson
2015-08-27 15:39 ` Andrew Cooper
2015-08-27 17:58 ` Ian Jackson
2015-08-27 18:16 ` Andrew Cooper
2015-08-28 17:16 ` Lars Kurth
2015-08-28 17:40 ` Andrew Cooper
2015-08-28 17:48 ` Andrew Cooper
2015-08-28 17:51 ` Lars Kurth
2015-08-28 18:18 ` Andrew Cooper
2015-08-28 18:52 ` Lars Kurth
2015-08-28 19:06 ` Andrew Cooper [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=55E0B130.4050708@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@citrix.com \
--cc=JBeulich@suse.com \
--cc=JGross@suse.com \
--cc=jfehlig@suse.com \
--cc=lars.kurth.xen@gmail.com \
--cc=lars.kurth@citrix.com \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.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 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.