Hi, As noted many times before, “optional” is next to non-existent for application programmers – especially if it’s important to achieve application portability. I’d suggest that API v1.0 would not have anything labeled as optional. It’s simplifies the API for everybody (implementers/testers/users). Features labeled as optional should be either turned into mandatory or dropped out.
-Petri From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of ext Bill Fischofer Sent: Monday, November 03, 2014 10:35 PM To: Shmulik Ladkani Cc: lng-odp@lists.linaro.org Subject: Re: [lng-odp] [Q] Memory allocation in ODP applications ODP APIs are divided into two classes: Mandatory, which all conforming ODP implementations are expected to provide, and Optional. The convention is that Optional APIs must be present but calling them may simply result in an ODP_FUNCTION_NOT_AVAILABLE return code. These are documented in the associated header files (currently under revision) and are part of the doxygen. Basically, unless an API calls itself out as OPTIONAL you should assume that all ODP implementations will provide functional implementations of it, though performance of individual APIs may vary between platforms and within platforms over time. It's expected that each platform will provide implementations of the ODP APIs that are optimized for that particular platform. ODP itself does not specify how implementations do that or how they might improve performance over time with subsequent releases of the implementation. This was the reason for decoupling the APIs from the implementations and supporting multiple repositories. It's expected that, over time, implementations will evolve and improve their performance as the implementations become better tuned to refinements in their underlying platform. Hope that helps. Bill On Mon, Nov 3, 2014 at 2:18 PM, Shmulik Ladkani <shmulik.ladk...@gmail.com<mailto:shmulik.ladk...@gmail.com>> wrote: On Mon, 3 Nov 2014 12:11:26 -0600 Bill Fischofer <bill.fischo...@linaro.org<mailto:bill.fischo...@linaro.org>> wrote: > ODP APIs are designed to be used *a la carte* by applications, as ODP is a > framework, not a platform. So feel free to mix malloc() or your own memory > management or other API calls in as needed. > > What ODP requires is the types specified in its APIs, so for example the > only way to get an odp_buffer_t is via the odp_buffer_alloc() call. > odp_buffer_alloc() in turn requires an odp_buffer_pool_t and that in turn > requires an odp_buffer_pool_create() call. > > ODP_BUFFER_TYPE_RAW simply exposes the basic block manager functions of the > ODP buffer APIs. Again, you're free to use them for whatever purpose the > application wants. Obviously one reason for doing so is to gain > portability across potentially different memory management implementations. Thanks Bill. This leads me to few additional questions: Are all memory-related ODP APIs mandatory (must be implemented by the platform)? Are they required to provide any other benefit over standard (or custom) allocation routines besides the portability guarantee? Regards, Shmulik
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
