You could be right. I had just imagined that helpers gets much bigger and would be something that may be omitted. It would provide meat to ODP like say a TCP/IP stack, DPI - regexp tools - something substantial but not of use to everyone, and something that does not change per platform, but is tightly coupled to using ODP APIs.
On 4 September 2014 15:32, Bill Fischofer <[email protected]> wrote: > Implementations are opaque to the application so whether or not an > implementation makes use of a helper function should be transparent to the > application, no? > > > > > On Thu, Sep 4, 2014 at 2:28 PM, Mike Holmes <[email protected]> > wrote: > >> Ok, that is a nice testable assumption for the validation tests, helpers >> should work perfectly before global_init. >> >> But the optional part of helpers gets lost if IPC uses it, then the ring >> helper is mandatory, that differs from me believing that an application >> could opt not use helpers at all and still use all the API. >> >> >> On 4 September 2014 15:23, Bill Fischofer <[email protected]> >> wrote: >> >>> By that definition, ODP implementations would be free to use helpers. >>> It's not that helpers cannot be used after odp_global_init() its that they >>> are the only routines that MAY be used before odp_global_init(). >>> >>> Yes, IPC is intended to be part of the ODP API so an application cannot >>> call IPC routines until after it has activated ODP via odp_global_init(). >>> >>> Bill >>> >>> >>> On Thu, Sep 4, 2014 at 2:19 PM, Mike Holmes <[email protected]> >>> wrote: >>> >>>> I think that is true by definition following Taras's logic from a >>>> thread a few weeks ago. The rational was that that helpers are users of the >>>> API to add higher functionality for an application to use, they don't help >>>> the implementation. >>>> >>>> However that breaks IPC I think, I have not read the latest patch, but >>>> that wants to use odph_ring.h - unless IPC is a helper, but I thought it >>>> was part of ODP. >>>> >>>> >>>> On 4 September 2014 14:59, Bill Fischofer <[email protected]> >>>> wrote: >>>> >>>>> Interesting point about ODP helper routines being used to help >>>>> construct odp_global_init() parameters. Are we saying that what makes a >>>>> helper a helper (from an application standpoint) is that it is a routine >>>>> that can be called before odp_global_init() since it is a stand-alone >>>>> function that operates independently from the rest of the ODP framework? >>>>> >>>>> That might be a good distinction and I'll make a note of it in the API >>>>> Design Guidelines doc. >>>>> >>>>> Bill >>>>> >>>>> >>>>> On Thu, Sep 4, 2014 at 1:43 PM, Mike Holmes <[email protected]> >>>>> wrote: >>>>> >>>>>> I am confused about the init sequence, I imagine this >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 4 September 2014 04:40, Santosh Shukla <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> On 4 September 2014 13:40, Savolainen, Petri (NSN - FI/Espoo) >>>>>>> <[email protected]> wrote: >>>>>>> >> Conti.. >>>>>>> >> >>>>>>> >> Root cause of my concern is not entirely specific to this patch. >>>>>>> Its >>>>>>> >> more related to odp api initialization calling sequence in >>>>>>> >> application. From early days, we used to follow below step in >>>>>>> >> application - >>>>>>> >> >>>>>>> >> odp_global_init() -> which does almost everything for platform >>>>>>> >> initialization. >>>>>>> >> odp_shm_reserve() -> used for argument processing then >>>>>>> >> odp_create_thread etc... >>>>>>> >> >>>>>>> >> Now we found a need to introduce platform specific init hints, >>>>>>> coming >>>>>>> >> from application. Therefore order of odp_xxx_init api calling >>>>>>> sequence >>>>>>> >> should change too. >>>>>>> >> >>>>>>> >> >>>>>>> >> Something like. >>>>>>> >> >>>>>>> >> Application "X" >>>>>>> >> >>>>>>> >> main () >>>>>>> >> { >>>>>>> >> >>>>>>> >> - First do argument processing. For that, call odp_shm_init() in >>>>>>> >> application and remove it from odp_global_init OR application has >>>>>>> to >>>>>>> >> allocate memory(bad idea ... I guess). >>>>>>> > >>>>>>> > argX and argY can be allocated from stack or heap (malloc). Shared >>>>>>> memory is not needed for those to be able to call odp_global_init(). ODP >>>>>>> will take copy of the argument, argX/Y can be destroyed after the call. >>>>>>> >>>>>>> Not to *call odp_global_init* , It is to pass command line processed >>>>>>> input to odp_globa_init().. Are you suggesting calling of >>>>>>> parse_args() >>>>>>> before and after odp_global_init()? >>>>>>> >>>>>>> >>>>>>> > >>>>>>> > After ODP init, you can allocate shm and copy args there if you >>>>>>> need to share those within your app. >>>>>>> >>>>>>> Same argument processed twice ? isn't it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> > >>>>>>> > -Petri >>>>>>> > >>>>>>> >> >>>>>>> >> - Then call odp_global/platform_init(argX, argY); where arg -X : >>>>>>> >> global param, Y : platform centric stuff. >>>>>>> >> >>>>>>> >> ... Rest stuff as it is. >>>>>>> >> } >>>>>>> >> >>>>>>> >> >>>>>>> >> Any idea? thoughts? Does above make sense. Thanks. >>>>>>> >> >>>>>>> >> >>>>>>> >>>>>> >>>>>> My view was that it went like this : >>>>>> >>>>>> >>>>>> main starts(args passed in) >>>>>> int foo; >>>>>> odp_init_t odp_data >>>>>> odp_platform_init_t platform_data >>>>>> >>>>>> /*Process the arguments passed in as normal.*/ >>>>>> loop { >>>>>> Set variables that main will use itself i.e. if --use-foo is passed >>>>>> set foo=true locally. >>>>>> Prepare odp_data to pass things into the implementation that ODP >>>>>> specifies, <- the internals of odp_data may be an argv string or a tidy >>>>>> struct we define populated by an ODP helper >>>>>> Prepare platform_data packaging any params required into the >>>>>> platform specific struct. <- Have no idea what these are, platform needs >>>>>> to figure this out >>>>>> } >>>>>> >>>>>> call global init(odp_data, platform_data) with the above >>>>>> >>>>>> ........ >>>>>> >>>>>> /* Act on any remaining parameters such as foo. */ >>>>>> if (foo) >>>>>> >>>>>> >>>>>> -- >>>>>> *Mike Holmes* >>>>>> Linaro Technical Manager / Lead >>>>>> LNG - ODP >>>>>> >>>>>> _______________________________________________ >>>>>> lng-odp mailing list >>>>>> [email protected] >>>>>> http://lists.linaro.org/mailman/listinfo/lng-odp >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> *Mike Holmes* >>>> Linaro Technical Manager / Lead >>>> LNG - ODP >>>> >>> >>> >> >> >> -- >> *Mike Holmes* >> Linaro Technical Manager / Lead >> LNG - ODP >> > > -- *Mike Holmes* Linaro Technical Manager / Lead LNG - ODP
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
