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