On 19 May 2016 at 06:05, Bill Fischofer <bill.fischo...@linaro.org> wrote:

> Signed-off-by: Bill Fischofer <bill.fischo...@linaro.org>
> ---
>  doc/users-guide/users-guide.adoc | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/doc/users-guide/users-guide.adoc
> b/doc/users-guide/users-guide.adoc
> index 62f5833..745b85f 100755
> --- a/doc/users-guide/users-guide.adoc
> +++ b/doc/users-guide/users-guide.adoc
> @@ -155,6 +155,17 @@ and minor release numbers correspond to the ODP API
> level that the suite
>  validates and the fix level represents the service level of the validation
>  suite itself for that API level.
>
> +=== ODP Helpers
> +ODP also provides a set of _helper_ functions that are
> +distinguished by the `odph_` prefix. These are not part of the ODP API
> +specification, but may be useful to both applications and implementations.
>

This statement allows for circular dependancy:
Using helpers from the application means that helpers will use ODP, as
helpers will perform usual stuff that application needs to do: for instance
helpers uses the ODP cpu_mask for creating threads, and helpers may do
other common application things toward ODP according to this definition.
Having things such as IP header description in helpers means that helpers
are needed by ODP:
In other words: helper is needed by ODP and needs ODP!
I know this is the situation today, but I am not sure we should write this
in stone. Maybe the helpers should be splitted as ODP_helpers and
APP_helpers?


> +This include things like mappings for common packet headers (IPv4, IPv6,
> +TCP, UDP, etc.) as well as wrapper functions for the Posix threading model
> +used in the odp-linux reference implementation of ODP. Helpers also
> provide
> +a home for utility APIs that are more experimental in nature and
> +are not part of the official ODP API specification. ODP helper APIs are
> +described further in the _ODP Helper Reference Manual_.
> +
>  === ODP Design Goals
>  ODP has three primary goals that follow from its component structure. The
> first
>  is application portability across a wide range of platforms. These
> platforms
> --
> 2.7.4
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to