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) < petri.savolai...@nsn.com> 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:* 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> > wrote: > > On Mon, 3 Nov 2014 12:11:26 -0600 Bill Fischofer < > 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
