I’m concerned that the API gets too fragmented already in v1.0 and the ecosystem will be limited by that. For example, it’s hard to integrate 3rd party (or open source) SW into a system, if my app uses optional feature X, the 3rd party lib uses optional feature Y and the implementation provides only one of those, or neither.
-Petri From: ext Bill Fischofer [mailto:[email protected]] Sent: Tuesday, November 04, 2014 3:16 PM To: Savolainen, Petri (NSN - FI/Espoo) Cc: Shmulik Ladkani; [email protected] Subject: Re: [lng-odp] [Q] Memory allocation in ODP applications I think the criteria I outlined above for considering an API optional are reasonable. Recall that the reason certain APIs are designated as optional is because we received feedback that they were not feasible on specific platforms. It's RECOMMENDED that platforms provide all of these APIs, however I'm not eager to say platform X can't have a conforming ODP implementation if it's just not feasible to implement every ODP API or feature on that platform. Applications will be written to whatever APIs and features they need. Not every application needs every API and feature and if an application needs an optional API then when it chooses which platforms it wants to deploy on it will take whether that platform provides that API into account in making its decision. These are fundamentally product marketing issues, not technical issues. If we take a one-size-fits-all approach that will unnecessarily limit the ecosystem. On Tue, Nov 4, 2014 at 6:43 AM, Savolainen, Petri (NSN - FI/Espoo) <[email protected]<mailto:[email protected]>> wrote: 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: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of ext Bill Fischofer Sent: Monday, November 03, 2014 10:35 PM To: Shmulik Ladkani Cc: [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> wrote: On Mon, 3 Nov 2014 12:11:26 -0600 Bill Fischofer <[email protected]<mailto:[email protected]>> 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 [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
