ODP helper should be cleaned up so that it only depends on the ODP public API and does not require implementations to provide internal platform support for the helpers. This is compounded by the notion that helpers should generally be callable before an odp_init call, indeed you might expect to be able to use odph_rings without calling any ODP_API. Neither of these goals if met currently.
Assuming that helpers should not use implementation internals we need to remove the following internal includes from the helpers :- odp_spin_internal.h odp_internal.h odp_debug_internal.h odp_align_internal.h I tried to clean this up and was successful with minimal change except that the ring helper implementation calls odp_spin() which is a more complex internal function of linux-generic. Given that Maxim wants to implement linux-generic PKTIO- IPC on the ring implementation that makes a mess:- Linux-generic will now depend on an odp helper that depends on the linux-generic internal implementation which is a bit of a loop. In the case of linux-generic it would make sense to make the ring functionality part of the internal implementation and drop it as a helper. Currently no test or application uses the ring helper so there would be no impact at all to this move. Since the ring is not a HW abstraction its API does not belong in the ODP API in my opinion, so I would keep the ring as an internal API of the linux-generic implementation. Derived works such as ODP-DPDK, ODP-NETMAP and ODP-KS2 can of course use the existing mechanisms to reuse the internal ring code for their implementations. Summary: As part of the decoupling I propose moving helper/ring.c -> platform/linux-generic/ring.c -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
