Ok, so the germane question so that I have the same image as you is, are helpers mandatory to the implementation ? I really got the impression they would not be.
With that spelled out I think it will be clear to me what "helpers" means On 4 September 2014 15:43, Bill Fischofer <[email protected]> wrote: > Something like a TCP/IP stack is a bit grandiose for a humble "helper" > designation. Sounds more like an ODP sharable service that could be used > by ODP applications. > > We can envision ODP applications being written as specific applications or > as general service routines that can be used in other ODP applications as > shared libraries. They'd assume they were being called from an ODP > application and had the ODP framework available to them. Beyond the scope > of ODP development per se, but certainly a reasonable part of a growing ODP > ecosystem. > > > On Thu, Sep 4, 2014 at 2:37 PM, Mike Holmes <[email protected]> > wrote: > >> 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 >> > > -- *Mike Holmes* Linaro Technical Manager / Lead LNG - ODP
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
