That's precisely why we've said that all implementations must provide at least stubs for all of the ODP APIs (even those marked optional). Not every ODP application will be able to run on every ODP implementation, but that's OK. You don't need your home office router to have enterprise-level features. Requiring every ODP implementation to provide identical functionality will either force us to adopt a least-common-denominator approach to what are acceptable APIs or else we'll severely limit the range of platforms that can participate in the ecosystem.
Do you have a specific list of APIs that are currently marked optional that you'd like to see promoted to mandatory? On Tue, Nov 4, 2014 at 7:26 AM, Savolainen, Petri (NSN - FI/Espoo) < petri.savolai...@nsn.com> wrote: > 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:bill.fischo...@linaro.org] > *Sent:* Tuesday, November 04, 2014 3:16 PM > *To:* Savolainen, Petri (NSN - FI/Espoo) > *Cc:* Shmulik Ladkani; lng-odp@lists.linaro.org > > *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) < > 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
