On 1/2/16, 12:52 PM, "Jan Viktorin" <viktorin at rehivetech.com> wrote:
>On Sat, 2 Jan 2016 18:35:08 +0000 >"Wiles, Keith" <keith.wiles at intel.com> wrote: > >> >Yes, DPDK needs to work in embedded environments with device tree. >> >Would it be possible reimplement device tree parsing in user space? >> >Ideally with a shared code from kernel?? >> >> Stephen, Do you mean we have to add kernel code to support DPDK on SoC >> Platforms? If that is the case I would like to not require code be added to >> the kernel to support DPDK. > >We will need a kernel module. But this is not necessarily related to the >device-tree parsing. > >> > >> >On a pratical level, the new SoC support must be optional >> >(via DPDK config infrastructure), since most architectures won't be using >> >it. >> >In most cases, it is better from usability if everything is runtime based, >> >but with SoC this is a platform/architecture configuration. >> >> I am not sure I agree with the optional support, as it could be stated that >> PCI support is optional on SoC platforms. It would be best to not treat SoC >> support as special compared to PCI support. Other then extra footprint it >> does not seem reasonable to require SoC support to be ifdef?ed in the code. >> Plus adding more ifdefs is not a good testing solution. > >This is a matter of preserving ABI. Turning PCI-support to be optional >seems to be a difficult step at the moment. Turning off PCI support is bit hard to do as well, I was looking for a way to execute the PCI or SoC code during startup. I think having both compiled into the DPDK , but figure out how to detect if that code needs to be run is the better solution as you have pointed out later. > >> >> Can we detect somehow we are on a system with SoC support or even a system >> that supports PCI for that matter? > >IMO, we can detect two things: "PCI is present on the system" and >"Device tree is accessible in /proc/device-tree". Is this acceptable? I guess this would be fine with me, as I do not like us to add ifdefs. > >-- > Jan Viktorin E-mail: Viktorin at RehiveTech.com > System Architect Web: www.RehiveTech.com > RehiveTech > Brno, Czech Republic > Regards, Keith