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
