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