DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Mcnamara, John" <john.mcnamara@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v1] doc: autogenerate nic overview table from ini files
Date: Fri, 8 Jul 2016 19:52:53 +0000	[thread overview]
Message-ID: <B27915DBBA3421428155699D51E4CFE20258D7E7@IRSMSX103.ger.corp.intel.com> (raw)
In-Reply-To: <1604656.XReoQ6n0NJ@xps13>

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Thursday, June 30, 2016 7:25 PM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1] doc: autogenerate nic overview table
> from ini files
> 
> 2016-06-30 19:03, John McNamara:
> > This patch converts the NIC feature table in the overview doc into a
> > set of ini files and adds some functions into the Sphinx conf.py file
> > to convert them back into an RST table.
> >
> Would it be possible to make it a bit more generic and reusable to
> generate other tables of this kind?

It would be possible (in the technical sense) but probably not worth the
effort. :-)


> > * Blank entries in the PMD ini files are optional. They will get a
> default
> >   blank entry in the RST table based on the entries in the default.ini
> file.
> >   The ini files in this patch were generated programmatically from the
> >   original RST table.
> 
> I don't think there is a benefit to have blank entries in the .ini file.
> And there would be less conflicts if the guideline was to avoid blank
> entries when adding a new feature.

I can generate a set of ini files without blank entries if that is the
preference.  For some PMDs that will mean that there are no entries in
the file, apart from the heading, but I guess that is okay.  I'll change
that in v2.

> 
> PDF output is restrictive :)

Yes, and the PDF infrastructure is a bit of a pain but we still get a lot
of people in the field who like them and ask for them after releases.

Maybe they read them on the beach, on holidays.

John

  parent reply	other threads:[~2016-07-08 19:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-30 18:03 John McNamara
2016-06-30 18:03 ` John McNamara
2016-06-30 18:25 ` Thomas Monjalon
2016-07-01  1:40   ` Yuanhan Liu
2016-07-08 19:52   ` Mcnamara, John [this message]
2016-07-17 12:59 ` [dpdk-dev] [PATCH v2] " John McNamara
2016-07-19 13:08   ` Ferruh Yigit
2016-07-29 11:59 ` [dpdk-dev] [PATCH v3] " John McNamara
2016-07-29 12:02   ` Mcnamara, John
2016-08-01 21:37   ` Thomas Monjalon
2016-08-03 14:32     ` Bruce Richardson
2016-08-03 16:44       ` Thomas Monjalon

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=B27915DBBA3421428155699D51E4CFE20258D7E7@IRSMSX103.ger.corp.intel.com \
    --to=john.mcnamara@intel.com \
    --cc=dev@dpdk.org \
    --cc=thomas.monjalon@6wind.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).