True, but maybe there is a middle way - What if instead of a mad matrix of optional features we have 2 or 3 levels of features? Say: ODP Basic support - all mandatory features are supported. ODP Full support - mandatory + all what we now call optional features are supported. And maybe, if it makes sense - ODP Intermediate support - mandatory + a certain pre-defined set of now called optional features supported. This let application writer to say: My application targets Basic, Intermediate or Full support and the application writer knows exactly what to expect. The platform vendor can say: I support ODP Basic, Intermediate or Full. So you know what you get.
Gilad Gilad Ben-Yossef Software Architect EZchip Technologies Ltd. 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel Tel: +972-4-959-6666 ext. 576, Fax: +972-8-681-1483 Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388 Email: gil...@ezchip.com, Web: http://www.ezchip.com "Ethernet always wins." — Andy Bechtolsheim > -----Original Message----- > From: lng-odp-boun...@lists.linaro.org [mailto:lng-odp- > boun...@lists.linaro.org] On Behalf Of Victor Kamensky > Sent: Tuesday, November 04, 2014 5:33 PM > To: Bill Fischofer > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp@lists.linaro.org > Subject: Re: [lng-odp] [Q] Memory allocation in ODP applications > > I did express the same in the past and agree with Petri > '“optional” is next to non-existent'. It creates fragmentation > that we don't need. When I need to figure out what optional > pieces implemented by specific ODP implementation and > how to match one that not implemented from that point > it is not very far for me just to create my own wrappers/shims > on top of specific SDKs. > > For optional APIs being present and return error in run-time > even worse in my opinion. Build time link error would be much > better. Because as usual run-time errors much harder to get > compared to build time errors. Build errors I discover during > single build, run-time errors I may need to create bunch of > specific scenarios to get complete coverage for pieces that > my app uses. > > Thanks, > Victor > > > On 4 November 2014 05:38, Bill Fischofer <bill.fischo...@linaro.org> > wrote: > > 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 > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
