Re: [dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri,  1 Jan 2016 22:05:20 +0100
Jan Viktorin <viktorin@rehivetech.com> wrote:

> Introduce the interface to SoC device infrastructure. A SoC device
> here means a device integrated on the chip via a (simple) bus
> that lacks of auto-discovery and other properties which are common
> for PCI. A counterpart in the Linux Kernel would be a platform_device
> (but this is not necessarily 1:1 mapping).
> 
> Systems without auto-discovery properties are described by a (Flat)
> Device Tree. Device Tree is usually available on embedded systems
> in /proc/device-tree. Every device has a unique path in the Device
> Tree and so it identifies every such device. This path is used
> to identify a device in rte_soc_addr.
> 
> Binding of drivers to devices in the Linux Kernel is often done
> by matching the compatible entry in the Device Tree. As there is
> no standard/generic way to read information like vendor, model, etc.
> from each SoC device, we match devices by the compatible entry too.
> The rte_soc_id contains an array of compatible strings telling what
> each device is compatible with.
> 
> There are no DPDK-specific OS drivers for SoC devices at the moment
> and unfortunately we cannot use the PCI-related ones as they contain
> too much PCI-specific logic.
> 
> Whitelisting and blacklisting of devices is based on the Device Tree
> identifier (rte_soc_addr) to mimic the PCI behaviour.
> 
> Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>

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??

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.

Do you consider this will break binary compatibility since
sizeof (rte_soc_addr) is PATH_MAX (1024) and the other elements of the
union inside rte_devargs are much smaller (like 32 bytes).