I think in a perfect world to achieve portability all ODP APIs should be mandatory, but that may be unrealistic and certainly some solutions would have terrible performance when emulated
Are there any dissenters from the idea that all ODP APIs are mandatory for 1.0 ? If not that is the plan of record for 1.0 and all APIs must function as specified. On 4 November 2014 11:35, Bill Fischofer <[email protected]> wrote: > We we want to call everything we've documented mandatory in v1.0 I'm OK > with that. What I don't want is for us to say that and then as we approach > end of year someone says "but I really can't do (formerly optional) feature > X". > > Quick poll: Are there any APIs currently marked optional that anyone does > not plan to implement in their v1.0 release? > > On Tue, Nov 4, 2014 at 9:58 AM, Gilad Ben Yossef <[email protected]> > wrote: > >> >> 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: [email protected], Web: http://www.ezchip.com >> >> "Ethernet always wins." >> — Andy Bechtolsheim >> >> > -----Original Message----- >> > From: [email protected] [mailto:lng-odp- >> > [email protected]] On Behalf Of Victor Kamensky >> > Sent: Tuesday, November 04, 2014 5:33 PM >> > To: Bill Fischofer >> > Cc: Savolainen, Petri (NSN - FI/Espoo); [email protected] >> > 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 <[email protected]> >> > 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) >> > > <[email protected]> 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:[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]> 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]] On Behalf Of ext Bill >> > Fischofer >> > >> Sent: Monday, November 03, 2014 10:35 PM >> > >> To: Shmulik Ladkani >> > >> Cc: [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]> wrote: >> > >> >> > >> On Mon, 3 Nov 2014 12:11:26 -0600 Bill Fischofer >> > >> <[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 >> > > >> > >> > _______________________________________________ >> > lng-odp mailing list >> > [email protected] >> > http://lists.linaro.org/mailman/listinfo/lng-odp >> > > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp > > -- *Mike Holmes* Linaro Sr Technical Manager LNG - ODP
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
