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 <gil...@ezchip.com> 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: 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
