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 >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
