On 26 March 2016 at 09:12, Jan Viktorin <viktorin at 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.
Jianbo
