From: Jan Viktorin <viktorin@rehivetech.com>
To: Jianbo Liu <jianbo.liu@linaro.org>
Cc: dev@dpdk.org, Thomas Monjalon <thomas.monjalon@6wind.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Keith Wiles <keith.wiles@intel.com>,
david.marchand@6wind.com,
Jerin Jacob <jerin.jacob@caviumnetworks.com>,
Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] [RFC 0/6] Flattened Device Tree access from DPDK
Date: Tue, 29 Mar 2016 12:34:29 +0200 [thread overview]
Message-ID: <20160329123429.2aa49c8a@pcviktorin.fit.vutbr.cz> (raw)
In-Reply-To: <CAP4Qi3-j-bRi4GPZj2GtYhbHKxhCSOCMKwAzYZzFjW2UHR1_dg@mail.gmail.com>
On Mon, 28 Mar 2016 10:43:00 +0800
Jianbo Liu <jianbo.liu@linaro.org> wrote:
> On 26 March 2016 at 09:12, Jan Viktorin <viktorin@rehivetech.com> wrote:
> > Hello,
> >
> > while extending the DPDK by a kind of platform devices (for the 16.07), an
> > access to the FDT might be necessary (or at least very helpful). This patch
> > series for 16.07 introduces an approach to solve this topic.
> >
> > The API is designed from scratch and there is only the Linux backend for it.
> > The Linux backend can read and traverse the /proc/device-tree structure. The
> > API, however, stays as independent as possible. It is possible to:
> >
> > * open the FDT in a platform independent way (rte_fdt_open/close)
> > * define a path in the FDT in an abstract way (rte_fdt_path)
> > * read strings, 32 and 64 bit values, a binary content (rte_fdt_path_readX)
> > * walk the FDT structure from a selected point (rte_fdt_path_walk)
> >
> > I've included unit tests of the API and of the Linux implemention. Some basic
> > API tests are introduced in the patch 3. Then a simplified device-tree file
> > structure is added together with more tests testing the Linux backend (4,5).
> > I've left those 3 patches separated for now but I think they can be aggregated
> > into a single patch later.
> >
> > Here, I've encounter an issue. The testing FDT files (app/test/linux-fdt) need
> > to be copied (or linked) to the working directory of the _test_ executable. I
> > have no idea, how to integrate such logic into the build system.
> >
> Why not store FDT files in the code, for example, as a group of binary arrays?
> When test is executed, it firstly creates the files in the working
> directory from those arrays.
Do you know some working solution of this? I am thinking of something
like objcopy of file contents, then link it to the test application.
This about extending the "test framework" a bit. Would somebody else
use such a feature?
Anyway, thank you for this idea.
Jan
>
> Jianbo
--
Jan Viktorin E-mail: Viktorin@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
prev parent reply other threads:[~2016-03-29 10:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-26 1:12 Jan Viktorin
2016-03-26 1:12 ` [dpdk-dev] [RFC 1/6] eal/fdt: introduce Flattened Device Tree API Jan Viktorin
2016-03-26 1:12 ` [dpdk-dev] [RFC 2/6] eal/fdt: implement FDT API for Linux Jan Viktorin
2016-03-26 1:12 ` [dpdk-dev] [RFC 3/6] eal/fdt: test FDT API Jan Viktorin
2016-03-26 1:12 ` [dpdk-dev] [RFC 4/6] eal/fdt: add testing FDT of xgene-1 got from Linux runtime Jan Viktorin
2016-03-26 1:12 ` [dpdk-dev] [RFC 5/6] eal/fdt: test FDT for Linux on real data source Jan Viktorin
2016-03-26 1:12 ` [dpdk-dev] [RFC 5/6] eal/fdt: test Linux implementation on xgene-1 FDT Jan Viktorin
2016-03-26 1:12 ` [dpdk-dev] [RFC 6/6] eal/fdt: export for dpdk 16.07 Jan Viktorin
2016-03-26 1:12 ` [dpdk-dev] [RFC 0/6] Flattened Device Tree access from DPDK Jan Viktorin
2016-03-28 2:43 ` Jianbo Liu
2016-03-29 10:34 ` Jan Viktorin [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=20160329123429.2aa49c8a@pcviktorin.fit.vutbr.cz \
--to=viktorin@rehivetech.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@6wind.com \
--cc=dev@dpdk.org \
--cc=jerin.jacob@caviumnetworks.com \
--cc=jianbo.liu@linaro.org \
--cc=keith.wiles@intel.com \
--cc=stephen@networkplumber.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).