| Message ID | 1407274197-44498-2-git-send-email-mike.holmes@linaro.org |
|---|---|
| State | Rejected |
| Headers | show |
On 6 August 2014 02:59, Mike Holmes <mike.holmes@linaro.org> wrote: > Signed-off-by: Mike Holmes <mike.holmes@linaro.org> > --- > test/api_test/odp_timer_ping.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/test/api_test/odp_timer_ping.c b/test/api_test/odp_timer_ping.c > index cd67e0d..ee5f318 100644 > --- a/test/api_test/odp_timer_ping.c > +++ b/test/api_test/odp_timer_ping.c > @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[] ODP_UNUSED) > /* Wait for worker threads to exit */ > odp_linux_pthread_join(thread_tbl, PING_THRD); > > - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ? "passed" : "failed"); > + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) ? "pass" : "fail"); > Reviewed-by : Santosh Shukla <santosh.shukla@linaro.org> > printf("ODP ping timer test complete\n\n"); > > -- > 1.9.1 > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp
On 2014-08-05 17:29, Mike Holmes wrote: > Signed-off-by: Mike Holmes <mike.holmes@linaro.org> > --- > test/api_test/odp_timer_ping.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/test/api_test/odp_timer_ping.c b/test/api_test/odp_timer_ping.c > index cd67e0d..ee5f318 100644 > --- a/test/api_test/odp_timer_ping.c > +++ b/test/api_test/odp_timer_ping.c > @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[] ODP_UNUSED) > /* Wait for worker threads to exit */ > odp_linux_pthread_join(thread_tbl, PING_THRD); > > - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ? "passed" : "failed"); > + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) ? "pass" : "fail"); if we try to fix the output format, shouldn't we fix change ODP_DEG to printf as well then so we always print out the results? Cheers, Anders > > printf("ODP ping timer test complete\n\n"); > > -- > 1.9.1 > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp
On 8 August 2014 04:11, Anders Roxell <anders.roxell@linaro.org> wrote: > On 2014-08-05 17:29, Mike Holmes wrote: >> Signed-off-by: Mike Holmes <mike.holmes@linaro.org> >> --- >> test/api_test/odp_timer_ping.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/test/api_test/odp_timer_ping.c b/test/api_test/odp_timer_ping.c >> index cd67e0d..ee5f318 100644 >> --- a/test/api_test/odp_timer_ping.c >> +++ b/test/api_test/odp_timer_ping.c >> @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[] ODP_UNUSED) >> /* Wait for worker threads to exit */ >> odp_linux_pthread_join(thread_tbl, PING_THRD); >> >> - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ? "passed" : "failed"); >> + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) ? "pass" : "fail"); > > if we try to fix the output format, shouldn't we fix change ODP_DEG to > printf as well then so we always print out the results? > I did not understood, Please elaborate more. Thanks. > Cheers, > Anders > >> >> printf("ODP ping timer test complete\n\n"); >> >> -- >> 1.9.1 >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/lng-odp > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp
On 8 August 2014 10:58, Santosh Shukla <santosh.shukla@linaro.org> wrote: > On 8 August 2014 04:11, Anders Roxell <anders.roxell@linaro.org> wrote: >> On 2014-08-05 17:29, Mike Holmes wrote: >>> Signed-off-by: Mike Holmes <mike.holmes@linaro.org> >>> --- >>> test/api_test/odp_timer_ping.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/test/api_test/odp_timer_ping.c b/test/api_test/odp_timer_ping.c >>> index cd67e0d..ee5f318 100644 >>> --- a/test/api_test/odp_timer_ping.c >>> +++ b/test/api_test/odp_timer_ping.c >>> @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[] ODP_UNUSED) >>> /* Wait for worker threads to exit */ >>> odp_linux_pthread_join(thread_tbl, PING_THRD); >>> >>> - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ? "passed" : "failed"); >>> + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) ? "pass" : "fail"); >> >> if we try to fix the output format, shouldn't we fix change ODP_DEG to >> printf as well then so we always print out the results? >> > > I did not understood, Please elaborate more. Thanks. Per chat discussion, You are right that ODP_DBG replaced with printf. However we do need better api like r / printf / odp_print and for such test resuit centric few more api's ( as you suggested them which I find quite right) odp_print_pass odp_print_fail Mike, Pl. replace odp_dbg with printf or if you choose to work on above proposed api through out the odp test / example app would be great. if so, till then we could hold this and yours other test patches. Whats you think ..anders/ Mike/ Maxim ?? >> Cheers, >> Anders >> >>> >>> printf("ODP ping timer test complete\n\n"); >>> >>> -- >>> 1.9.1 >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org >>> http://lists.linaro.org/mailman/listinfo/lng-odp >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/lng-odp
On 08/08/2014 10:41 AM, Santosh Shukla wrote: > On 8 August 2014 10:58, Santosh Shukla <santosh.shukla@linaro.org> wrote: >> On 8 August 2014 04:11, Anders Roxell <anders.roxell@linaro.org> wrote: >>> On 2014-08-05 17:29, Mike Holmes wrote: >>>> Signed-off-by: Mike Holmes <mike.holmes@linaro.org> >>>> --- >>>> test/api_test/odp_timer_ping.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/test/api_test/odp_timer_ping.c b/test/api_test/odp_timer_ping.c >>>> index cd67e0d..ee5f318 100644 >>>> --- a/test/api_test/odp_timer_ping.c >>>> +++ b/test/api_test/odp_timer_ping.c >>>> @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[] ODP_UNUSED) >>>> /* Wait for worker threads to exit */ >>>> odp_linux_pthread_join(thread_tbl, PING_THRD); >>>> >>>> - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ? "passed" : "failed"); >>>> + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) ? "pass" : "fail"); >>> >>> if we try to fix the output format, shouldn't we fix change ODP_DEG to >>> printf as well then so we always print out the results? >>> >> >> I did not understood, Please elaborate more. Thanks. > > Per chat discussion, You are right that ODP_DBG replaced with printf. > However we do > need better api like r / printf / odp_print > > and for such test resuit centric few more api's ( as you suggested > them which I find quite right) > > odp_print_pass > odp_print_fail > > > Mike, Pl. replace odp_dbg with printf or if you choose to work on > above proposed api through out the odp test / example app would be > great. if so, till then we could hold this and yours other test > patches. Whats you think ..anders/ Mike/ Maxim ?? In KS2 implementation I'm using prints that mimics Linux kernel print functions. See below. odp_pr_info() can be used for test result print. Does it make sense to push these changes to linux-generic? #define ODP_PRINT_LEVEL_CRIT 1 #define ODP_PRINT_LEVEL_ERR 2 #define ODP_PRINT_LEVEL_WARN 3 #define ODP_PRINT_LEVEL_INFO 4 #define ODP_PRINT_LEVEL_DBG 5 #define ODP_PRINT_LEVEL_VDBG 6 #define ODP_PRINT_LEVEL_MAX 7 #define ODP_PRINT_LEVEL ODP_PRINT_LEVEL_DBG /** * Debug printing macro */ #ifndef ODP_NO_PRINT #define ODP_PRINT(level, fmt, ...) \ do { if (level <= ODP_PRINT_LEVEL) \ fprintf(stderr, "%s:%d:%s(): " fmt, __FILE__, \ __LINE__, __func__, ##__VA_ARGS__); \ } while (0) #else #define ODP_PRINT(level, fmt, ...) #endif #define odp_pr_err(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_ERR, fmt, ##__VA_ARGS__) #define odp_pr_warn(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_WARN, fmt, ##__VA_ARGS__) #define odp_pr_info(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_INFO, fmt, ##__VA_ARGS__) #define odp_pr_dbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_DBG, fmt, ##__VA_ARGS__) #define odp_pr_vdbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_VDBG, fmt, ##__VA_ARGS__)
On 2014-08-08 13:08, Taras Kondratiuk wrote: > On 08/08/2014 10:41 AM, Santosh Shukla wrote: > > On 8 August 2014 10:58, Santosh Shukla <santosh.shukla@linaro.org> wrote: > >> On 8 August 2014 04:11, Anders Roxell <anders.roxell@linaro.org> wrote: > >>> On 2014-08-05 17:29, Mike Holmes wrote: > >>>> Signed-off-by: Mike Holmes <mike.holmes@linaro.org> > >>>> --- > >>>> test/api_test/odp_timer_ping.c | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>>> diff --git a/test/api_test/odp_timer_ping.c b/test/api_test/odp_timer_ping.c > >>>> index cd67e0d..ee5f318 100644 > >>>> --- a/test/api_test/odp_timer_ping.c > >>>> +++ b/test/api_test/odp_timer_ping.c > >>>> @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[] ODP_UNUSED) > >>>> /* Wait for worker threads to exit */ > >>>> odp_linux_pthread_join(thread_tbl, PING_THRD); > >>>> > >>>> - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ? "passed" : "failed"); > >>>> + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) ? "pass" : "fail"); > >>> > >>> if we try to fix the output format, shouldn't we fix change ODP_DEG to > >>> printf as well then so we always print out the results? > >>> > >> > >> I did not understood, Please elaborate more. Thanks. > > > > Per chat discussion, You are right that ODP_DBG replaced with printf. > > However we do > > need better api like r / printf / odp_print > > > > and for such test resuit centric few more api's ( as you suggested > > them which I find quite right) > > > > odp_print_pass > > odp_print_fail > > > > > > Mike, Pl. replace odp_dbg with printf or if you choose to work on > > above proposed api through out the odp test / example app would be > > great. if so, till then we could hold this and yours other test > > patches. Whats you think ..anders/ Mike/ Maxim ?? > > In KS2 implementation I'm using prints that mimics Linux kernel print > functions. See below. odp_pr_info() can be used for test result print. > Does it make sense to push these changes to linux-generic? > > #define ODP_PRINT_LEVEL_CRIT 1 > #define ODP_PRINT_LEVEL_ERR 2 > #define ODP_PRINT_LEVEL_WARN 3 > #define ODP_PRINT_LEVEL_INFO 4 > #define ODP_PRINT_LEVEL_DBG 5 > #define ODP_PRINT_LEVEL_VDBG 6 > #define ODP_PRINT_LEVEL_MAX 7 > > #define ODP_PRINT_LEVEL ODP_PRINT_LEVEL_DBG > > /** > * Debug printing macro > */ > #ifndef ODP_NO_PRINT > #define ODP_PRINT(level, fmt, ...) \ > do { if (level <= ODP_PRINT_LEVEL) \ > fprintf(stderr, "%s:%d:%s(): " fmt, __FILE__, \ > __LINE__, __func__, ##__VA_ARGS__); \ > } while (0) > #else > #define ODP_PRINT(level, fmt, ...) > #endif > > #define odp_pr_err(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_ERR, fmt, ##__VA_ARGS__) > #define odp_pr_warn(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_WARN, fmt, ##__VA_ARGS__) > #define odp_pr_info(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_INFO, fmt, ##__VA_ARGS__) > #define odp_pr_dbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_DBG, fmt, ##__VA_ARGS__) > #define odp_pr_vdbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_VDBG, fmt, ##__VA_ARGS__) I like this idea, and I guess we can add something like odp_pr_test_pass and odp_pr_test_fail into some common header file in the test directory. Or is that to over do it? Cheers, Anders
I like ODP_PRINT, but not going mad with even more macros for pass and fail, how would you then mix in tests that return measurement data, I don't think that is flexible enough and you end up with macro soup. What needs to be abstracted is the print, adding levels of print is fine but then you get into heated wars about what is a level 1 vs a level 7. I am not sure there should be a CRIT that should be a call to ODP_ERR <http://docs.opendataplane.org/arch/html/odp__debug_8h.html#ac62ed05a943d97b01ead4468afe11cab> which is specifically called out as redirectable to an error stream that matters to the application on that platform. So maybe we need to re work ODP_ERR and include all these in that idea of a log that can be used for postmortem in a real system. On 8 August 2014 06:43, Anders Roxell <anders.roxell@linaro.org> wrote: > On 2014-08-08 13:08, Taras Kondratiuk wrote: > > On 08/08/2014 10:41 AM, Santosh Shukla wrote: > > > On 8 August 2014 10:58, Santosh Shukla <santosh.shukla@linaro.org> > wrote: > > >> On 8 August 2014 04:11, Anders Roxell <anders.roxell@linaro.org> > wrote: > > >>> On 2014-08-05 17:29, Mike Holmes wrote: > > >>>> Signed-off-by: Mike Holmes <mike.holmes@linaro.org> > > >>>> --- > > >>>> test/api_test/odp_timer_ping.c | 2 +- > > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > > >>>> > > >>>> diff --git a/test/api_test/odp_timer_ping.c > b/test/api_test/odp_timer_ping.c > > >>>> index cd67e0d..ee5f318 100644 > > >>>> --- a/test/api_test/odp_timer_ping.c > > >>>> +++ b/test/api_test/odp_timer_ping.c > > >>>> @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[] > ODP_UNUSED) > > >>>> /* Wait for worker threads to exit */ > > >>>> odp_linux_pthread_join(thread_tbl, PING_THRD); > > >>>> > > >>>> - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ? > "passed" : "failed"); > > >>>> + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) > ? "pass" : "fail"); > > >>> > > >>> if we try to fix the output format, shouldn't we fix change ODP_DEG > to > > >>> printf as well then so we always print out the results? > > >>> > > >> > > >> I did not understood, Please elaborate more. Thanks. > > > > > > Per chat discussion, You are right that ODP_DBG replaced with printf. > > > However we do > > > need better api like r / printf / odp_print > > > > > > and for such test resuit centric few more api's ( as you suggested > > > them which I find quite right) > > > > > > odp_print_pass > > > odp_print_fail > > > > > > > > > Mike, Pl. replace odp_dbg with printf or if you choose to work on > > > above proposed api through out the odp test / example app would be > > > great. if so, till then we could hold this and yours other test > > > patches. Whats you think ..anders/ Mike/ Maxim ?? > > > > In KS2 implementation I'm using prints that mimics Linux kernel print > > functions. See below. odp_pr_info() can be used for test result print. > > Does it make sense to push these changes to linux-generic? > > > > #define ODP_PRINT_LEVEL_CRIT 1 > > #define ODP_PRINT_LEVEL_ERR 2 > > #define ODP_PRINT_LEVEL_WARN 3 > > #define ODP_PRINT_LEVEL_INFO 4 > > #define ODP_PRINT_LEVEL_DBG 5 > > #define ODP_PRINT_LEVEL_VDBG 6 > > #define ODP_PRINT_LEVEL_MAX 7 > > > > #define ODP_PRINT_LEVEL ODP_PRINT_LEVEL_DBG > > > > /** > > * Debug printing macro > > */ > > #ifndef ODP_NO_PRINT > > #define ODP_PRINT(level, fmt, ...) \ > > do { if (level <= ODP_PRINT_LEVEL) \ > > fprintf(stderr, "%s:%d:%s(): " fmt, __FILE__, \ > > __LINE__, __func__, ##__VA_ARGS__); \ > > } while (0) > > #else > > #define ODP_PRINT(level, fmt, ...) > > #endif > > > > #define odp_pr_err(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_ERR, fmt, > ##__VA_ARGS__) > > #define odp_pr_warn(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_WARN, fmt, > ##__VA_ARGS__) > > #define odp_pr_info(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_INFO, fmt, > ##__VA_ARGS__) > > #define odp_pr_dbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_DBG, fmt, > ##__VA_ARGS__) > > #define odp_pr_vdbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_VDBG, fmt, > ##__VA_ARGS__) > > I like this idea, and I guess we can add something like odp_pr_test_pass > and odp_pr_test_fail into some common header file in the test directory. > Or is that to over do it? > > Cheers, > Anders > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp >
Even better, We're missing debug level. Anyone working on or plan to migrate linux-generic to ODP_PRINT? Taras, one question in my mind, what is ODP_PRINT_LEVEL_VDBG? specific to keystone and we don't need this in linux-generic. On 8 August 2014 16:13, Anders Roxell <anders.roxell@linaro.org> wrote: > On 2014-08-08 13:08, Taras Kondratiuk wrote: >> On 08/08/2014 10:41 AM, Santosh Shukla wrote: >> > On 8 August 2014 10:58, Santosh Shukla <santosh.shukla@linaro.org> wrote: >> >> On 8 August 2014 04:11, Anders Roxell <anders.roxell@linaro.org> wrote: >> >>> On 2014-08-05 17:29, Mike Holmes wrote: >> >>>> Signed-off-by: Mike Holmes <mike.holmes@linaro.org> >> >>>> --- >> >>>> test/api_test/odp_timer_ping.c | 2 +- >> >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >> >>>> >> >>>> diff --git a/test/api_test/odp_timer_ping.c b/test/api_test/odp_timer_ping.c >> >>>> index cd67e0d..ee5f318 100644 >> >>>> --- a/test/api_test/odp_timer_ping.c >> >>>> +++ b/test/api_test/odp_timer_ping.c >> >>>> @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[] ODP_UNUSED) >> >>>> /* Wait for worker threads to exit */ >> >>>> odp_linux_pthread_join(thread_tbl, PING_THRD); >> >>>> >> >>>> - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ? "passed" : "failed"); >> >>>> + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) ? "pass" : "fail"); >> >>> >> >>> if we try to fix the output format, shouldn't we fix change ODP_DEG to >> >>> printf as well then so we always print out the results? >> >>> >> >> >> >> I did not understood, Please elaborate more. Thanks. >> > >> > Per chat discussion, You are right that ODP_DBG replaced with printf. >> > However we do >> > need better api like r / printf / odp_print >> > >> > and for such test resuit centric few more api's ( as you suggested >> > them which I find quite right) >> > >> > odp_print_pass >> > odp_print_fail >> > >> > >> > Mike, Pl. replace odp_dbg with printf or if you choose to work on >> > above proposed api through out the odp test / example app would be >> > great. if so, till then we could hold this and yours other test >> > patches. Whats you think ..anders/ Mike/ Maxim ?? >> >> In KS2 implementation I'm using prints that mimics Linux kernel print >> functions. See below. odp_pr_info() can be used for test result print. >> Does it make sense to push these changes to linux-generic? >> >> #define ODP_PRINT_LEVEL_CRIT 1 >> #define ODP_PRINT_LEVEL_ERR 2 >> #define ODP_PRINT_LEVEL_WARN 3 >> #define ODP_PRINT_LEVEL_INFO 4 >> #define ODP_PRINT_LEVEL_DBG 5 >> #define ODP_PRINT_LEVEL_VDBG 6 >> #define ODP_PRINT_LEVEL_MAX 7 >> >> #define ODP_PRINT_LEVEL ODP_PRINT_LEVEL_DBG >> >> /** >> * Debug printing macro >> */ >> #ifndef ODP_NO_PRINT >> #define ODP_PRINT(level, fmt, ...) \ >> do { if (level <= ODP_PRINT_LEVEL) \ >> fprintf(stderr, "%s:%d:%s(): " fmt, __FILE__, \ >> __LINE__, __func__, ##__VA_ARGS__); \ >> } while (0) >> #else >> #define ODP_PRINT(level, fmt, ...) >> #endif >> >> #define odp_pr_err(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_ERR, fmt, ##__VA_ARGS__) >> #define odp_pr_warn(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_WARN, fmt, ##__VA_ARGS__) >> #define odp_pr_info(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_INFO, fmt, ##__VA_ARGS__) >> #define odp_pr_dbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_DBG, fmt, ##__VA_ARGS__) >> #define odp_pr_vdbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_VDBG, fmt, ##__VA_ARGS__) > > I like this idea, and I guess we can add something like odp_pr_test_pass > and odp_pr_test_fail into some common header file in the test directory. > Or is that to over do it? > > Cheers, > Anders
Remember last printf level discussion and It went for long time :) . Mike, not for all the levels but keeping ODP_PRINT for _LEVEL_INFO makes sense. On 8 August 2014 16:47, Mike Holmes <mike.holmes@linaro.org> wrote: > I like ODP_PRINT, but not going mad with even more macros for pass and > fail, how would you then mix in tests that return measurement data, I don't > think that is flexible enough and you end up with macro soup. > What needs to be abstracted is the print, adding levels of print is fine but > then you get into heated wars about what is a level 1 vs a level 7. > > I am not sure there should be a CRIT that should be a call to ODP_ERR which > is specifically called out as redirectable to an error stream that matters > to the application on that platform. So maybe we need to re work ODP_ERR > and include all these in that idea of a log that can be used for postmortem > in a real system. > > > > > On 8 August 2014 06:43, Anders Roxell <anders.roxell@linaro.org> wrote: >> >> On 2014-08-08 13:08, Taras Kondratiuk wrote: >> > On 08/08/2014 10:41 AM, Santosh Shukla wrote: >> > > On 8 August 2014 10:58, Santosh Shukla <santosh.shukla@linaro.org> >> > > wrote: >> > >> On 8 August 2014 04:11, Anders Roxell <anders.roxell@linaro.org> >> > >> wrote: >> > >>> On 2014-08-05 17:29, Mike Holmes wrote: >> > >>>> Signed-off-by: Mike Holmes <mike.holmes@linaro.org> >> > >>>> --- >> > >>>> test/api_test/odp_timer_ping.c | 2 +- >> > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >> > >>>> >> > >>>> diff --git a/test/api_test/odp_timer_ping.c >> > >>>> b/test/api_test/odp_timer_ping.c >> > >>>> index cd67e0d..ee5f318 100644 >> > >>>> --- a/test/api_test/odp_timer_ping.c >> > >>>> +++ b/test/api_test/odp_timer_ping.c >> > >>>> @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[] >> > >>>> ODP_UNUSED) >> > >>>> /* Wait for worker threads to exit */ >> > >>>> odp_linux_pthread_join(thread_tbl, PING_THRD); >> > >>>> >> > >>>> - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ? >> > >>>> "passed" : "failed"); >> > >>>> + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) >> > >>>> ? "pass" : "fail"); >> > >>> >> > >>> if we try to fix the output format, shouldn't we fix change ODP_DEG >> > >>> to >> > >>> printf as well then so we always print out the results? >> > >>> >> > >> >> > >> I did not understood, Please elaborate more. Thanks. >> > > >> > > Per chat discussion, You are right that ODP_DBG replaced with printf. >> > > However we do >> > > need better api like r / printf / odp_print >> > > >> > > and for such test resuit centric few more api's ( as you suggested >> > > them which I find quite right) >> > > >> > > odp_print_pass >> > > odp_print_fail >> > > >> > > >> > > Mike, Pl. replace odp_dbg with printf or if you choose to work on >> > > above proposed api through out the odp test / example app would be >> > > great. if so, till then we could hold this and yours other test >> > > patches. Whats you think ..anders/ Mike/ Maxim ?? >> > >> > In KS2 implementation I'm using prints that mimics Linux kernel print >> > functions. See below. odp_pr_info() can be used for test result print. >> > Does it make sense to push these changes to linux-generic? >> > >> > #define ODP_PRINT_LEVEL_CRIT 1 >> > #define ODP_PRINT_LEVEL_ERR 2 >> > #define ODP_PRINT_LEVEL_WARN 3 >> > #define ODP_PRINT_LEVEL_INFO 4 >> > #define ODP_PRINT_LEVEL_DBG 5 >> > #define ODP_PRINT_LEVEL_VDBG 6 >> > #define ODP_PRINT_LEVEL_MAX 7 >> > >> > #define ODP_PRINT_LEVEL ODP_PRINT_LEVEL_DBG >> > >> > /** >> > * Debug printing macro >> > */ >> > #ifndef ODP_NO_PRINT >> > #define ODP_PRINT(level, fmt, ...) \ >> > do { if (level <= ODP_PRINT_LEVEL) \ >> > fprintf(stderr, "%s:%d:%s(): " fmt, __FILE__, \ >> > __LINE__, __func__, ##__VA_ARGS__); \ >> > } while (0) >> > #else >> > #define ODP_PRINT(level, fmt, ...) >> > #endif >> > >> > #define odp_pr_err(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_ERR, fmt, >> > ##__VA_ARGS__) >> > #define odp_pr_warn(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_WARN, fmt, >> > ##__VA_ARGS__) >> > #define odp_pr_info(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_INFO, fmt, >> > ##__VA_ARGS__) >> > #define odp_pr_dbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_DBG, fmt, >> > ##__VA_ARGS__) >> > #define odp_pr_vdbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_VDBG, fmt, >> > ##__VA_ARGS__) >> >> I like this idea, and I guess we can add something like odp_pr_test_pass >> and odp_pr_test_fail into some common header file in the test directory. >> Or is that to over do it? >> >> Cheers, >> Anders >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > -- > Mike Holmes > Linaro Technical Manager / Lead > LNG - ODP > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp >
On 08/08/2014 02:24 PM, Santosh Shukla wrote: > Even better, We're missing debug level. Anyone working on or plan to > migrate linux-generic to ODP_PRINT? > > Taras, one question in my mind, what is ODP_PRINT_LEVEL_VDBG? specific > to keystone and we don't need this in linux-generic. That is a verbose debug.
Without a clear definition of what all of these levels mean and when a
certain level should be used, too much granularity does not make sense
("too much choice!"). Does the Linux kernel include such a definition we
also can reuse?
A real managed application would support different log levels but also log
classes (different modules would belong to different log classes but
perhaps ODP would be a log class in itself), logging would always be
compiled-in. But I don't think this is what we are aiming for. *What are we
aiming for?*
-- Ola
On 8 August 2014 12:08, Taras Kondratiuk <taras.kondratiuk@linaro.org>
wrote:
> On 08/08/2014 10:41 AM, Santosh Shukla wrote:
> > On 8 August 2014 10:58, Santosh Shukla <santosh.shukla@linaro.org>
> wrote:
> >> On 8 August 2014 04:11, Anders Roxell <anders.roxell@linaro.org> wrote:
> >>> On 2014-08-05 17:29, Mike Holmes wrote:
> >>>> Signed-off-by: Mike Holmes <mike.holmes@linaro.org>
> >>>> ---
> >>>> test/api_test/odp_timer_ping.c | 2 +-
> >>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/test/api_test/odp_timer_ping.c
> b/test/api_test/odp_timer_ping.c
> >>>> index cd67e0d..ee5f318 100644
> >>>> --- a/test/api_test/odp_timer_ping.c
> >>>> +++ b/test/api_test/odp_timer_ping.c
> >>>> @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[]
> ODP_UNUSED)
> >>>> /* Wait for worker threads to exit */
> >>>> odp_linux_pthread_join(thread_tbl, PING_THRD);
> >>>>
> >>>> - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ?
> "passed" : "failed");
> >>>> + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) ?
> "pass" : "fail");
> >>>
> >>> if we try to fix the output format, shouldn't we fix change ODP_DEG to
> >>> printf as well then so we always print out the results?
> >>>
> >>
> >> I did not understood, Please elaborate more. Thanks.
> >
> > Per chat discussion, You are right that ODP_DBG replaced with printf.
> > However we do
> > need better api like r / printf / odp_print
> >
> > and for such test resuit centric few more api's ( as you suggested
> > them which I find quite right)
> >
> > odp_print_pass
> > odp_print_fail
> >
> >
> > Mike, Pl. replace odp_dbg with printf or if you choose to work on
> > above proposed api through out the odp test / example app would be
> > great. if so, till then we could hold this and yours other test
> > patches. Whats you think ..anders/ Mike/ Maxim ??
>
> In KS2 implementation I'm using prints that mimics Linux kernel print
> functions. See below. odp_pr_info() can be used for test result print.
> Does it make sense to push these changes to linux-generic?
>
> #define ODP_PRINT_LEVEL_CRIT 1
> #define ODP_PRINT_LEVEL_ERR 2
> #define ODP_PRINT_LEVEL_WARN 3
> #define ODP_PRINT_LEVEL_INFO 4
> #define ODP_PRINT_LEVEL_DBG 5
> #define ODP_PRINT_LEVEL_VDBG 6
> #define ODP_PRINT_LEVEL_MAX 7
>
> #define ODP_PRINT_LEVEL ODP_PRINT_LEVEL_DBG
>
> /**
> * Debug printing macro
> */
> #ifndef ODP_NO_PRINT
> #define ODP_PRINT(level, fmt, ...) \
> do { if (level <= ODP_PRINT_LEVEL) \
> fprintf(stderr, "%s:%d:%s(): " fmt, __FILE__, \
> __LINE__, __func__, ##__VA_ARGS__); \
> } while (0)
> #else
> #define ODP_PRINT(level, fmt, ...)
> #endif
>
> #define odp_pr_err(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_ERR, fmt,
> ##__VA_ARGS__)
> #define odp_pr_warn(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_WARN, fmt,
> ##__VA_ARGS__)
> #define odp_pr_info(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_INFO, fmt,
> ##__VA_ARGS__)
> #define odp_pr_dbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_DBG, fmt,
> ##__VA_ARGS__)
> #define odp_pr_vdbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_VDBG, fmt,
> ##__VA_ARGS__)
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
We are aiming for hooks that allow ODP to fit in exactly as you describe Ola, we don't want to create the final solution, every system has its own set up. I have been involved a lot of postmortem log generation for carriers and a few things come to mind that matter. You need to be able to enable per functional area - say classification, crypto so that you don't overwhelm which is likely to be a limited ring buffer in memory that traces the last few seconds of what was occurring. It must be possible to comple out some of the most verbose logging that just can't be sustained in a real system - but that level depends on the system Generally it is a huge benefit to be able to turn on some level of debug whilst in the field rather than send a debug build and wait for something to reoccur. I think we should establish:- per module hooks that default to printf right now. I think we want only five types, ERROR, WARNING, INFO, DBG examples: Error = cannot continue warning = out of memory, probably the application can free something and re try info = allocated crypto session trace = entered this function / left this function. dbg = not normally needed details. All of the above are per crypto, classification, buffers etc On 11 August 2014 09:44, Ola Liljedahl <ola.liljedahl@linaro.org> wrote: > Without a clear definition of what all of these levels mean and when a > certain level should be used, too much granularity does not make sense > ("too much choice!"). Does the Linux kernel include such a definition we > also can reuse? > > A real managed application would support different log levels but also log > classes (different modules would belong to different log classes but > perhaps ODP would be a log class in itself), logging would always be > compiled-in. But I don't think this is what we are aiming for. *What are > we aiming for?* > > -- Ola > > > > On 8 August 2014 12:08, Taras Kondratiuk <taras.kondratiuk@linaro.org> > wrote: > >> On 08/08/2014 10:41 AM, Santosh Shukla wrote: >> > On 8 August 2014 10:58, Santosh Shukla <santosh.shukla@linaro.org> >> wrote: >> >> On 8 August 2014 04:11, Anders Roxell <anders.roxell@linaro.org> >> wrote: >> >>> On 2014-08-05 17:29, Mike Holmes wrote: >> >>>> Signed-off-by: Mike Holmes <mike.holmes@linaro.org> >> >>>> --- >> >>>> test/api_test/odp_timer_ping.c | 2 +- >> >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >> >>>> >> >>>> diff --git a/test/api_test/odp_timer_ping.c >> b/test/api_test/odp_timer_ping.c >> >>>> index cd67e0d..ee5f318 100644 >> >>>> --- a/test/api_test/odp_timer_ping.c >> >>>> +++ b/test/api_test/odp_timer_ping.c >> >>>> @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[] >> ODP_UNUSED) >> >>>> /* Wait for worker threads to exit */ >> >>>> odp_linux_pthread_join(thread_tbl, PING_THRD); >> >>>> >> >>>> - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ? >> "passed" : "failed"); >> >>>> + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) ? >> "pass" : "fail"); >> >>> >> >>> if we try to fix the output format, shouldn't we fix change ODP_DEG to >> >>> printf as well then so we always print out the results? >> >>> >> >> >> >> I did not understood, Please elaborate more. Thanks. >> > >> > Per chat discussion, You are right that ODP_DBG replaced with printf. >> > However we do >> > need better api like r / printf / odp_print >> > >> > and for such test resuit centric few more api's ( as you suggested >> > them which I find quite right) >> > >> > odp_print_pass >> > odp_print_fail >> > >> > >> > Mike, Pl. replace odp_dbg with printf or if you choose to work on >> > above proposed api through out the odp test / example app would be >> > great. if so, till then we could hold this and yours other test >> > patches. Whats you think ..anders/ Mike/ Maxim ?? >> >> In KS2 implementation I'm using prints that mimics Linux kernel print >> functions. See below. odp_pr_info() can be used for test result print. >> Does it make sense to push these changes to linux-generic? >> >> #define ODP_PRINT_LEVEL_CRIT 1 >> #define ODP_PRINT_LEVEL_ERR 2 >> #define ODP_PRINT_LEVEL_WARN 3 >> #define ODP_PRINT_LEVEL_INFO 4 >> #define ODP_PRINT_LEVEL_DBG 5 >> #define ODP_PRINT_LEVEL_VDBG 6 >> #define ODP_PRINT_LEVEL_MAX 7 >> >> #define ODP_PRINT_LEVEL ODP_PRINT_LEVEL_DBG >> >> /** >> * Debug printing macro >> */ >> #ifndef ODP_NO_PRINT >> #define ODP_PRINT(level, fmt, ...) \ >> do { if (level <= ODP_PRINT_LEVEL) \ >> fprintf(stderr, "%s:%d:%s(): " fmt, __FILE__, \ >> __LINE__, __func__, ##__VA_ARGS__); \ >> } while (0) >> #else >> #define ODP_PRINT(level, fmt, ...) >> #endif >> >> #define odp_pr_err(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_ERR, fmt, >> ##__VA_ARGS__) >> #define odp_pr_warn(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_WARN, fmt, >> ##__VA_ARGS__) >> #define odp_pr_info(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_INFO, fmt, >> ##__VA_ARGS__) >> #define odp_pr_dbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_DBG, fmt, >> ##__VA_ARGS__) >> #define odp_pr_vdbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_VDBG, fmt, >> ##__VA_ARGS__) >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/lng-odp >> > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp > >
If log messages should be compiled-in all the time (at least when using the
default build configuration), then we need a very low-overhead mechanism
which can avoid parameter construction and even the function call, should
logging not be enabled for this specific message.
I suggest a simple two-dimensional model where each log message is
associated with a source indication and a severity level. The source
indicator identifies the source (e.g. module, block or function) of the log
message, the severity number identifies some sort of severity level (debug,
warning, error etc). Then we need a control interface to set the log level
for a source.
Severity level is a simple scalar, probably with some predefined levels
(e.g. ODP_LOG_DEBUG etc).
For the source indication, we need extensibility, can't limit this to some
predefined set of sources. We don't mind if the application also starts
using the ODP log mechanism.
Modules in the code should be able to register log sources, it could
specify a pointer to a (static) integer variable. The log manager keeps a
list of all log sources and their corresponding log variables.
uint32_t odp_queue_loglevel; //Need volatile?
//register log source "queue" with pointer to odp_queue_loglevel
//report a message to the log
//put this code in a suitable macro, e.g. ODP_LOG(odp_queue_loglevel,
ODP_LOG_WARNING, formatstring, parameters)
if (odp_unlikely(odp_queue_loglevel >= ODP_LOG_WARNING)) {
printf("log message\n", parameters); //Or maybe a call into the log
manager which can be redirected at runtime
}
If logging is disabled for this source and severity level, we only get a
load, compare and a not taken branch
On 11 August 2014 16:09, Mike Holmes <mike.holmes@linaro.org> wrote:
> We are aiming for hooks that allow ODP to fit in exactly as you describe
> Ola, we don't want to create the final solution, every system has its own
> set up.
>
> I have been involved a lot of postmortem log generation for carriers and a
> few things come to mind that matter.
>
> You need to be able to enable per functional area - say classification,
> crypto so that you don't overwhelm which is likely to be a limited ring
> buffer in memory that traces the last few seconds of what was occurring.
>
> It must be possible to comple out some of the most verbose logging that
> just can't be sustained in a real system - but that level depends on the
> system
>
> Generally it is a huge benefit to be able to turn on some level of debug
> whilst in the field rather than send a debug build and wait for something
> to reoccur.
>
> I think we should establish:-
>
> per module hooks that default to printf right now.
> I think we want only five types, ERROR, WARNING, INFO, DBG
>
> examples:
> Error = cannot continue
> warning = out of memory, probably the application can free something and
> re try
> info = allocated crypto session
> trace = entered this function / left this function.
> dbg = not normally needed details.
>
> All of the above are per crypto, classification, buffers etc
>
>
>
>
> On 11 August 2014 09:44, Ola Liljedahl <ola.liljedahl@linaro.org> wrote:
>
>> Without a clear definition of what all of these levels mean and when a
>> certain level should be used, too much granularity does not make sense
>> ("too much choice!"). Does the Linux kernel include such a definition we
>> also can reuse?
>>
>> A real managed application would support different log levels but also
>> log classes (different modules would belong to different log classes but
>> perhaps ODP would be a log class in itself), logging would always be
>> compiled-in. But I don't think this is what we are aiming for. *What are
>> we aiming for?*
>>
>> -- Ola
>>
>>
>>
>> On 8 August 2014 12:08, Taras Kondratiuk <taras.kondratiuk@linaro.org>
>> wrote:
>>
>>> On 08/08/2014 10:41 AM, Santosh Shukla wrote:
>>> > On 8 August 2014 10:58, Santosh Shukla <santosh.shukla@linaro.org>
>>> wrote:
>>> >> On 8 August 2014 04:11, Anders Roxell <anders.roxell@linaro.org>
>>> wrote:
>>> >>> On 2014-08-05 17:29, Mike Holmes wrote:
>>> >>>> Signed-off-by: Mike Holmes <mike.holmes@linaro.org>
>>> >>>> ---
>>> >>>> test/api_test/odp_timer_ping.c | 2 +-
>>> >>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> >>>>
>>> >>>> diff --git a/test/api_test/odp_timer_ping.c
>>> b/test/api_test/odp_timer_ping.c
>>> >>>> index cd67e0d..ee5f318 100644
>>> >>>> --- a/test/api_test/odp_timer_ping.c
>>> >>>> +++ b/test/api_test/odp_timer_ping.c
>>> >>>> @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[]
>>> ODP_UNUSED)
>>> >>>> /* Wait for worker threads to exit */
>>> >>>> odp_linux_pthread_join(thread_tbl, PING_THRD);
>>> >>>>
>>> >>>> - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ?
>>> "passed" : "failed");
>>> >>>> + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0)
>>> ? "pass" : "fail");
>>> >>>
>>> >>> if we try to fix the output format, shouldn't we fix change ODP_DEG
>>> to
>>> >>> printf as well then so we always print out the results?
>>> >>>
>>> >>
>>> >> I did not understood, Please elaborate more. Thanks.
>>> >
>>> > Per chat discussion, You are right that ODP_DBG replaced with printf.
>>> > However we do
>>> > need better api like r / printf / odp_print
>>> >
>>> > and for such test resuit centric few more api's ( as you suggested
>>> > them which I find quite right)
>>> >
>>> > odp_print_pass
>>> > odp_print_fail
>>> >
>>> >
>>> > Mike, Pl. replace odp_dbg with printf or if you choose to work on
>>> > above proposed api through out the odp test / example app would be
>>> > great. if so, till then we could hold this and yours other test
>>> > patches. Whats you think ..anders/ Mike/ Maxim ??
>>>
>>> In KS2 implementation I'm using prints that mimics Linux kernel print
>>> functions. See below. odp_pr_info() can be used for test result print.
>>> Does it make sense to push these changes to linux-generic?
>>>
>>> #define ODP_PRINT_LEVEL_CRIT 1
>>> #define ODP_PRINT_LEVEL_ERR 2
>>> #define ODP_PRINT_LEVEL_WARN 3
>>> #define ODP_PRINT_LEVEL_INFO 4
>>> #define ODP_PRINT_LEVEL_DBG 5
>>> #define ODP_PRINT_LEVEL_VDBG 6
>>> #define ODP_PRINT_LEVEL_MAX 7
>>>
>>> #define ODP_PRINT_LEVEL ODP_PRINT_LEVEL_DBG
>>>
>>> /**
>>> * Debug printing macro
>>> */
>>> #ifndef ODP_NO_PRINT
>>> #define ODP_PRINT(level, fmt, ...) \
>>> do { if (level <= ODP_PRINT_LEVEL) \
>>> fprintf(stderr, "%s:%d:%s(): " fmt, __FILE__, \
>>> __LINE__, __func__, ##__VA_ARGS__); \
>>> } while (0)
>>> #else
>>> #define ODP_PRINT(level, fmt, ...)
>>> #endif
>>>
>>> #define odp_pr_err(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_ERR, fmt,
>>> ##__VA_ARGS__)
>>> #define odp_pr_warn(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_WARN, fmt,
>>> ##__VA_ARGS__)
>>> #define odp_pr_info(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_INFO, fmt,
>>> ##__VA_ARGS__)
>>> #define odp_pr_dbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_DBG, fmt,
>>> ##__VA_ARGS__)
>>> #define odp_pr_vdbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_VDBG, fmt,
>>> ##__VA_ARGS__)
>>>
>>> _______________________________________________
>>> lng-odp mailing list
>>> lng-odp@lists.linaro.org
>>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>>
>>
>>
>> _______________________________________________
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>
>>
>
>
> --
> *Mike Holmes*
> Linaro Technical Manager / Lead
> LNG - ODP
>
I would like to be able to compile out logging and if logging is compiled into the code then I need to be able to control logging (on/off and increase/decrease logging). When logging (or any feature) is compiled out of the code then all of the logging statements are removed as in
// Just made up some logging macro
#ifdef INCLUDE_ODP_LOGGING
extern int global_flag;
#define LOG(flag, …) do { if (flag & global_flag) printf(args); } while((0))
#else
#define LOG(flag, ...) do { } while((0)
#endif
Maybe this is what you are getting at already.
Thanks
++Keith
Keith Wiles, Principal Technologist with CTO office, Wind River mobile 972-213-5533
On Aug 12, 2014, at 10:45 AM, Ola Liljedahl <ola.liljedahl@linaro.org<mailto:ola.liljedahl@linaro.org>> wrote:
If log messages should be compiled-in all the time (at least when using the default build configuration), then we need a very low-overhead mechanism which can avoid parameter construction and even the function call, should logging not be enabled for this specific message.
I suggest a simple two-dimensional model where each log message is associated with a source indication and a severity level. The source indicator identifies the source (e.g. module, block or function) of the log message, the severity number identifies some sort of severity level (debug, warning, error etc). Then we need a control interface to set the log level for a source.
Severity level is a simple scalar, probably with some predefined levels (e.g. ODP_LOG_DEBUG etc).
For the source indication, we need extensibility, can't limit this to some predefined set of sources. We don't mind if the application also starts using the ODP log mechanism.
Modules in the code should be able to register log sources, it could specify a pointer to a (static) integer variable. The log manager keeps a list of all log sources and their corresponding log variables.
uint32_t odp_queue_loglevel; //Need volatile?
//register log source "queue" with pointer to odp_queue_loglevel
//report a message to the log
//put this code in a suitable macro, e.g. ODP_LOG(odp_queue_loglevel, ODP_LOG_WARNING, formatstring, parameters)
if (odp_unlikely(odp_queue_loglevel >= ODP_LOG_WARNING)) {
printf("log message\n", parameters); //Or maybe a call into the log manager which can be redirected at runtime
}
If logging is disabled for this source and severity level, we only get a load, compare and a not taken branch
On 11 August 2014 16:09, Mike Holmes <mike.holmes@linaro.org<mailto:mike.holmes@linaro.org>> wrote:
We are aiming for hooks that allow ODP to fit in exactly as you describe Ola, we don't want to create the final solution, every system has its own set up.
I have been involved a lot of postmortem log generation for carriers and a few things come to mind that matter.
You need to be able to enable per functional area - say classification, crypto so that you don't overwhelm which is likely to be a limited ring buffer in memory that traces the last few seconds of what was occurring.
It must be possible to comple out some of the most verbose logging that just can't be sustained in a real system - but that level depends on the system
Generally it is a huge benefit to be able to turn on some level of debug whilst in the field rather than send a debug build and wait for something to reoccur.
I think we should establish:-
per module hooks that default to printf right now.
I think we want only five types, ERROR, WARNING, INFO, DBG
examples:
Error = cannot continue
warning = out of memory, probably the application can free something and re try
info = allocated crypto session
trace = entered this function / left this function.
dbg = not normally needed details.
All of the above are per crypto, classification, buffers etc
On 11 August 2014 09:44, Ola Liljedahl <ola.liljedahl@linaro.org<mailto:ola.liljedahl@linaro.org>> wrote:
Without a clear definition of what all of these levels mean and when a certain level should be used, too much granularity does not make sense ("too much choice!"). Does the Linux kernel include such a definition we also can reuse?
A real managed application would support different log levels but also log classes (different modules would belong to different log classes but perhaps ODP would be a log class in itself), logging would always be compiled-in. But I don't think this is what we are aiming for. What are we aiming for?
-- Ola
On 8 August 2014 12:08, Taras Kondratiuk <taras.kondratiuk@linaro.org<mailto:taras.kondratiuk@linaro.org>> wrote:
On 08/08/2014 10:41 AM, Santosh Shukla wrote:
> On 8 August 2014 10:58, Santosh Shukla <santosh.shukla@linaro.org<mailto:santosh.shukla@linaro.org>> wrote:
>> On 8 August 2014 04:11, Anders Roxell <anders.roxell@linaro.org<mailto:anders.roxell@linaro.org>> wrote:
>>> On 2014-08-05 17:29, Mike Holmes wrote:
>>>> Signed-off-by: Mike Holmes <mike.holmes@linaro.org<mailto:mike.holmes@linaro.org>>
>>>> ---
>>>> test/api_test/odp_timer_ping.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/test/api_test/odp_timer_ping.c b/test/api_test/odp_timer_ping.c
>>>> index cd67e0d..ee5f318 100644
>>>> --- a/test/api_test/odp_timer_ping.c
>>>> +++ b/test/api_test/odp_timer_ping.c
>>>> @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[] ODP_UNUSED)
>>>> /* Wait for worker threads to exit */
>>>> odp_linux_pthread_join(thread_tbl, PING_THRD);
>>>>
>>>> - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ? "passed" : "failed");
>>>> + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) ? "pass" : "fail");
>>>
>>> if we try to fix the output format, shouldn't we fix change ODP_DEG to
>>> printf as well then so we always print out the results?
>>>
>>
>> I did not understood, Please elaborate more. Thanks.
>
> Per chat discussion, You are right that ODP_DBG replaced with printf.
> However we do
> need better api like r / printf / odp_print
>
> and for such test resuit centric few more api's ( as you suggested
> them which I find quite right)
>
> odp_print_pass
> odp_print_fail
>
>
> Mike, Pl. replace odp_dbg with printf or if you choose to work on
> above proposed api through out the odp test / example app would be
> great. if so, till then we could hold this and yours other test
> patches. Whats you think ..anders/ Mike/ Maxim ??
In KS2 implementation I'm using prints that mimics Linux kernel print
functions. See below. odp_pr_info() can be used for test result print.
Does it make sense to push these changes to linux-generic?
#define ODP_PRINT_LEVEL_CRIT 1
#define ODP_PRINT_LEVEL_ERR 2
#define ODP_PRINT_LEVEL_WARN 3
#define ODP_PRINT_LEVEL_INFO 4
#define ODP_PRINT_LEVEL_DBG 5
#define ODP_PRINT_LEVEL_VDBG 6
#define ODP_PRINT_LEVEL_MAX 7
#define ODP_PRINT_LEVEL ODP_PRINT_LEVEL_DBG
/**
* Debug printing macro
*/
#ifndef ODP_NO_PRINT
#define ODP_PRINT(level, fmt, ...) \
do { if (level <= ODP_PRINT_LEVEL) \
fprintf(stderr, "%s:%d:%s(): " fmt, __FILE__, \
__LINE__, __func__, ##__VA_ARGS__); \
} while (0)
#else
#define ODP_PRINT(level, fmt, ...)
#endif
#define odp_pr_err(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_ERR, fmt, ##__VA_ARGS__)
#define odp_pr_warn(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_WARN, fmt, ##__VA_ARGS__)
#define odp_pr_info(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_INFO, fmt, ##__VA_ARGS__)
#define odp_pr_dbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_DBG, fmt, ##__VA_ARGS__)
#define odp_pr_vdbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_VDBG, fmt, ##__VA_ARGS__)
As per Victors comments, we also identified the need for callback as the sync for the messages so that applications rather than implementations decide how to consume the data. On 12 August 2014 12:00, Wiles, Roger Keith <keith.wiles@windriver.com> wrote: > I would like to be able to compile out logging and if logging is compiled > into the code then I need to be able to control logging (on/off and > increase/decrease logging). When logging (or any feature) is compiled out > of the code then all of the logging statements are removed as in > > // Just made up some logging macro > #ifdef INCLUDE_ODP_LOGGING > extern int global_flag; > #define LOG(flag, …) do { if (flag & global_flag) printf(args); } > while((0)) > #else > #define LOG(flag, ...) do { } while((0) > #endif > > Maybe this is what you are getting at already. > > Thanks > ++Keith > *Keith **Wiles*, Principal Technologist with CTO office, *Wind River *mobile > 972-213-5533 > > On Aug 12, 2014, at 10:45 AM, Ola Liljedahl <ola.liljedahl@linaro.org> > wrote: > > If log messages should be compiled-in all the time (at least when using > the default build configuration), then we need a very low-overhead > mechanism which can avoid parameter construction and even the function > call, should logging not be enabled for this specific message. > > I suggest a simple two-dimensional model where each log message is > associated with a source indication and a severity level. The source > indicator identifies the source (e.g. module, block or function) of the log > message, the severity number identifies some sort of severity level (debug, > warning, error etc). Then we need a control interface to set the log level > for a source. > > Severity level is a simple scalar, probably with some predefined levels > (e.g. ODP_LOG_DEBUG etc). > For the source indication, we need extensibility, can't limit this to > some predefined set of sources. We don't mind if the application also > starts using the ODP log mechanism. > > Modules in the code should be able to register log sources, it could > specify a pointer to a (static) integer variable. The log manager keeps a > list of all log sources and their corresponding log variables. > > uint32_t odp_queue_loglevel; //Need volatile? > //register log source "queue" with pointer to odp_queue_loglevel > > //report a message to the log > //put this code in a suitable macro, e.g. ODP_LOG(odp_queue_loglevel, > ODP_LOG_WARNING, formatstring, parameters) > if (odp_unlikely(odp_queue_loglevel >= ODP_LOG_WARNING)) { > printf("log message\n", parameters); //Or maybe a call into the log > manager which can be redirected at runtime > } > If logging is disabled for this source and severity level, we only get a > load, compare and a not taken branch > > > On 11 August 2014 16:09, Mike Holmes <mike.holmes@linaro.org> wrote: > >> We are aiming for hooks that allow ODP to fit in exactly as you describe >> Ola, we don't want to create the final solution, every system has its own >> set up. >> >> I have been involved a lot of postmortem log generation for carriers >> and a few things come to mind that matter. >> >> You need to be able to enable per functional area - say classification, >> crypto so that you don't overwhelm which is likely to be a limited ring >> buffer in memory that traces the last few seconds of what was occurring. >> >> It must be possible to comple out some of the most verbose logging that >> just can't be sustained in a real system - but that level depends on the >> system >> >> Generally it is a huge benefit to be able to turn on some level of >> debug whilst in the field rather than send a debug build and wait for >> something to reoccur. >> >> I think we should establish:- >> >> per module hooks that default to printf right now. >> I think we want only five types, ERROR, WARNING, INFO, DBG >> >> examples: >> Error = cannot continue >> warning = out of memory, probably the application can free something and >> re try >> info = allocated crypto session >> trace = entered this function / left this function. >> dbg = not normally needed details. >> >> All of the above are per crypto, classification, buffers etc >> >> >> >> >> On 11 August 2014 09:44, Ola Liljedahl <ola.liljedahl@linaro.org> wrote: >> >>> Without a clear definition of what all of these levels mean and when a >>> certain level should be used, too much granularity does not make sense >>> ("too much choice!"). Does the Linux kernel include such a definition we >>> also can reuse? >>> >>> A real managed application would support different log levels but also >>> log classes (different modules would belong to different log classes but >>> perhaps ODP would be a log class in itself), logging would always be >>> compiled-in. But I don't think this is what we are aiming for. *What >>> are we aiming for?* >>> >>> -- Ola >>> >>> >>> >>> On 8 August 2014 12:08, Taras Kondratiuk <taras.kondratiuk@linaro.org> >>> wrote: >>> >>>> On 08/08/2014 10:41 AM, Santosh Shukla wrote: >>>> > On 8 August 2014 10:58, Santosh Shukla <santosh.shukla@linaro.org> >>>> wrote: >>>> >> On 8 August 2014 04:11, Anders Roxell <anders.roxell@linaro.org> >>>> wrote: >>>> >>> On 2014-08-05 17:29, Mike Holmes wrote: >>>> >>>> Signed-off-by: Mike Holmes <mike.holmes@linaro.org> >>>> >>>> --- >>>> >>>> test/api_test/odp_timer_ping.c | 2 +- >>>> >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> >>>> >>>> diff --git a/test/api_test/odp_timer_ping.c >>>> b/test/api_test/odp_timer_ping.c >>>> >>>> index cd67e0d..ee5f318 100644 >>>> >>>> --- a/test/api_test/odp_timer_ping.c >>>> >>>> +++ b/test/api_test/odp_timer_ping.c >>>> >>>> @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[] >>>> ODP_UNUSED) >>>> >>>> /* Wait for worker threads to exit */ >>>> >>>> odp_linux_pthread_join(thread_tbl, PING_THRD); >>>> >>>> >>>> >>>> - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ? >>>> "passed" : "failed"); >>>> >>>> + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) >>>> ? "pass" : "fail"); >>>> >>> >>>> >>> if we try to fix the output format, shouldn't we fix change ODP_DEG >>>> to >>>> >>> printf as well then so we always print out the results? >>>> >>> >>>> >> >>>> >> I did not understood, Please elaborate more. Thanks. >>>> > >>>> > Per chat discussion, You are right that ODP_DBG replaced with printf. >>>> > However we do >>>> > need better api like r / printf / odp_print >>>> > >>>> > and for such test resuit centric few more api's ( as you suggested >>>> > them which I find quite right) >>>> > >>>> > odp_print_pass >>>> > odp_print_fail >>>> > >>>> > >>>> > Mike, Pl. replace odp_dbg with printf or if you choose to work on >>>> > above proposed api through out the odp test / example app would be >>>> > great. if so, till then we could hold this and yours other test >>>> > patches. Whats you think ..anders/ Mike/ Maxim ?? >>>> >>>> In KS2 implementation I'm using prints that mimics Linux kernel print >>>> functions. See below. odp_pr_info() can be used for test result print. >>>> Does it make sense to push these changes to linux-generic? >>>> >>>> #define ODP_PRINT_LEVEL_CRIT 1 >>>> #define ODP_PRINT_LEVEL_ERR 2 >>>> #define ODP_PRINT_LEVEL_WARN 3 >>>> #define ODP_PRINT_LEVEL_INFO 4 >>>> #define ODP_PRINT_LEVEL_DBG 5 >>>> #define ODP_PRINT_LEVEL_VDBG 6 >>>> #define ODP_PRINT_LEVEL_MAX 7 >>>> >>>> #define ODP_PRINT_LEVEL ODP_PRINT_LEVEL_DBG >>>> >>>> /** >>>> * Debug printing macro >>>> */ >>>> #ifndef ODP_NO_PRINT >>>> #define ODP_PRINT(level, fmt, ...) \ >>>> do { if (level <= ODP_PRINT_LEVEL) \ >>>> fprintf(stderr, "%s:%d:%s(): " fmt, __FILE__, \ >>>> __LINE__, __func__, ##__VA_ARGS__); \ >>>> } while (0) >>>> #else >>>> #define ODP_PRINT(level, fmt, ...) >>>> #endif >>>> >>>> #define odp_pr_err(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_ERR, fmt, >>>> ##__VA_ARGS__) >>>> #define odp_pr_warn(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_WARN, fmt, >>>> ##__VA_ARGS__) >>>> #define odp_pr_info(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_INFO, fmt, >>>> ##__VA_ARGS__) >>>> #define odp_pr_dbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_DBG, fmt, >>>> ##__VA_ARGS__) >>>> #define odp_pr_vdbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_VDBG, fmt, >>>> ##__VA_ARGS__) >>>> >>>> _______________________________________________ >>>> lng-odp mailing list >>>> lng-odp@lists.linaro.org >>>> http://lists.linaro.org/mailman/listinfo/lng-odp >>>> >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org >>> http://lists.linaro.org/mailman/listinfo/lng-odp >>> >>> >> >> >> -- >> *Mike Holmes* >> Linaro Technical Manager / Lead >> LNG - ODP >> > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp > > >
Always compiled in (but possibly dormant) or compile-time configurable, that's the question... Then one day an already deployed application starts to misbehave and you really want to be able to get some info about what is happening before the program bellies up. A core dump (for post mortem debugging) is one good thing to have. The ability to selectively turn on logging is another feature most critical applications and systems have. On 12 August 2014 18:00, Wiles, Roger Keith <keith.wiles@windriver.com> wrote: > I would like to be able to compile out logging and if logging is compiled > into the code then I need to be able to control logging (on/off and > increase/decrease logging). When logging (or any feature) is compiled out > of the code then all of the logging statements are removed as in > > // Just made up some logging macro > #ifdef INCLUDE_ODP_LOGGING > extern int global_flag; > #define LOG(flag, …) do { if (flag & global_flag) printf(args); } > while((0)) > #else > #define LOG(flag, ...) do { } while((0) > #endif > > Maybe this is what you are getting at already. > > Thanks > ++Keith > *Keith **Wiles*, Principal Technologist with CTO office, *Wind River *mobile > 972-213-5533 > > On Aug 12, 2014, at 10:45 AM, Ola Liljedahl <ola.liljedahl@linaro.org> > wrote: > > If log messages should be compiled-in all the time (at least when using > the default build configuration), then we need a very low-overhead > mechanism which can avoid parameter construction and even the function > call, should logging not be enabled for this specific message. > > I suggest a simple two-dimensional model where each log message is > associated with a source indication and a severity level. The source > indicator identifies the source (e.g. module, block or function) of the log > message, the severity number identifies some sort of severity level (debug, > warning, error etc). Then we need a control interface to set the log level > for a source. > > Severity level is a simple scalar, probably with some predefined levels > (e.g. ODP_LOG_DEBUG etc). > For the source indication, we need extensibility, can't limit this to > some predefined set of sources. We don't mind if the application also > starts using the ODP log mechanism. > > Modules in the code should be able to register log sources, it could > specify a pointer to a (static) integer variable. The log manager keeps a > list of all log sources and their corresponding log variables. > > uint32_t odp_queue_loglevel; //Need volatile? > //register log source "queue" with pointer to odp_queue_loglevel > > //report a message to the log > //put this code in a suitable macro, e.g. ODP_LOG(odp_queue_loglevel, > ODP_LOG_WARNING, formatstring, parameters) > if (odp_unlikely(odp_queue_loglevel >= ODP_LOG_WARNING)) { > printf("log message\n", parameters); //Or maybe a call into the log > manager which can be redirected at runtime > } > If logging is disabled for this source and severity level, we only get a > load, compare and a not taken branch > > > On 11 August 2014 16:09, Mike Holmes <mike.holmes@linaro.org> wrote: > >> We are aiming for hooks that allow ODP to fit in exactly as you describe >> Ola, we don't want to create the final solution, every system has its own >> set up. >> >> I have been involved a lot of postmortem log generation for carriers >> and a few things come to mind that matter. >> >> You need to be able to enable per functional area - say classification, >> crypto so that you don't overwhelm which is likely to be a limited ring >> buffer in memory that traces the last few seconds of what was occurring. >> >> It must be possible to comple out some of the most verbose logging that >> just can't be sustained in a real system - but that level depends on the >> system >> >> Generally it is a huge benefit to be able to turn on some level of >> debug whilst in the field rather than send a debug build and wait for >> something to reoccur. >> >> I think we should establish:- >> >> per module hooks that default to printf right now. >> I think we want only five types, ERROR, WARNING, INFO, DBG >> >> examples: >> Error = cannot continue >> warning = out of memory, probably the application can free something and >> re try >> info = allocated crypto session >> trace = entered this function / left this function. >> dbg = not normally needed details. >> >> All of the above are per crypto, classification, buffers etc >> >> >> >> >> On 11 August 2014 09:44, Ola Liljedahl <ola.liljedahl@linaro.org> wrote: >> >>> Without a clear definition of what all of these levels mean and when a >>> certain level should be used, too much granularity does not make sense >>> ("too much choice!"). Does the Linux kernel include such a definition we >>> also can reuse? >>> >>> A real managed application would support different log levels but also >>> log classes (different modules would belong to different log classes but >>> perhaps ODP would be a log class in itself), logging would always be >>> compiled-in. But I don't think this is what we are aiming for. *What >>> are we aiming for?* >>> >>> -- Ola >>> >>> >>> >>> On 8 August 2014 12:08, Taras Kondratiuk <taras.kondratiuk@linaro.org> >>> wrote: >>> >>>> On 08/08/2014 10:41 AM, Santosh Shukla wrote: >>>> > On 8 August 2014 10:58, Santosh Shukla <santosh.shukla@linaro.org> >>>> wrote: >>>> >> On 8 August 2014 04:11, Anders Roxell <anders.roxell@linaro.org> >>>> wrote: >>>> >>> On 2014-08-05 17:29, Mike Holmes wrote: >>>> >>>> Signed-off-by: Mike Holmes <mike.holmes@linaro.org> >>>> >>>> --- >>>> >>>> test/api_test/odp_timer_ping.c | 2 +- >>>> >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> >>>> >>>> diff --git a/test/api_test/odp_timer_ping.c >>>> b/test/api_test/odp_timer_ping.c >>>> >>>> index cd67e0d..ee5f318 100644 >>>> >>>> --- a/test/api_test/odp_timer_ping.c >>>> >>>> +++ b/test/api_test/odp_timer_ping.c >>>> >>>> @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[] >>>> ODP_UNUSED) >>>> >>>> /* Wait for worker threads to exit */ >>>> >>>> odp_linux_pthread_join(thread_tbl, PING_THRD); >>>> >>>> >>>> >>>> - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ? >>>> "passed" : "failed"); >>>> >>>> + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) >>>> ? "pass" : "fail"); >>>> >>> >>>> >>> if we try to fix the output format, shouldn't we fix change ODP_DEG >>>> to >>>> >>> printf as well then so we always print out the results? >>>> >>> >>>> >> >>>> >> I did not understood, Please elaborate more. Thanks. >>>> > >>>> > Per chat discussion, You are right that ODP_DBG replaced with printf. >>>> > However we do >>>> > need better api like r / printf / odp_print >>>> > >>>> > and for such test resuit centric few more api's ( as you suggested >>>> > them which I find quite right) >>>> > >>>> > odp_print_pass >>>> > odp_print_fail >>>> > >>>> > >>>> > Mike, Pl. replace odp_dbg with printf or if you choose to work on >>>> > above proposed api through out the odp test / example app would be >>>> > great. if so, till then we could hold this and yours other test >>>> > patches. Whats you think ..anders/ Mike/ Maxim ?? >>>> >>>> In KS2 implementation I'm using prints that mimics Linux kernel print >>>> functions. See below. odp_pr_info() can be used for test result print. >>>> Does it make sense to push these changes to linux-generic? >>>> >>>> #define ODP_PRINT_LEVEL_CRIT 1 >>>> #define ODP_PRINT_LEVEL_ERR 2 >>>> #define ODP_PRINT_LEVEL_WARN 3 >>>> #define ODP_PRINT_LEVEL_INFO 4 >>>> #define ODP_PRINT_LEVEL_DBG 5 >>>> #define ODP_PRINT_LEVEL_VDBG 6 >>>> #define ODP_PRINT_LEVEL_MAX 7 >>>> >>>> #define ODP_PRINT_LEVEL ODP_PRINT_LEVEL_DBG >>>> >>>> /** >>>> * Debug printing macro >>>> */ >>>> #ifndef ODP_NO_PRINT >>>> #define ODP_PRINT(level, fmt, ...) \ >>>> do { if (level <= ODP_PRINT_LEVEL) \ >>>> fprintf(stderr, "%s:%d:%s(): " fmt, __FILE__, \ >>>> __LINE__, __func__, ##__VA_ARGS__); \ >>>> } while (0) >>>> #else >>>> #define ODP_PRINT(level, fmt, ...) >>>> #endif >>>> >>>> #define odp_pr_err(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_ERR, fmt, >>>> ##__VA_ARGS__) >>>> #define odp_pr_warn(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_WARN, fmt, >>>> ##__VA_ARGS__) >>>> #define odp_pr_info(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_INFO, fmt, >>>> ##__VA_ARGS__) >>>> #define odp_pr_dbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_DBG, fmt, >>>> ##__VA_ARGS__) >>>> #define odp_pr_vdbg(fmt, ...) ODP_PRINT(ODP_PRINT_LEVEL_VDBG, fmt, >>>> ##__VA_ARGS__) >>>> >>>> _______________________________________________ >>>> lng-odp mailing list >>>> lng-odp@lists.linaro.org >>>> http://lists.linaro.org/mailman/listinfo/lng-odp >>>> >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org >>> http://lists.linaro.org/mailman/listinfo/lng-odp >>> >>> >> >> >> -- >> *Mike Holmes* >> Linaro Technical Manager / Lead >> LNG - ODP >> > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp > > >
On 08/12/2014 10:35 PM, Ola Liljedahl wrote: > Always compiled in (but possibly dormant) or compile-time > configurable, that's the question... > > Then one day an already deployed application starts to misbehave and > you really want to be able to get some info about what is happening > before the program bellies up. A core dump (for post mortem debugging) > is one good thing to have. The ability to selectively turn on logging > is another feature most critical applications and systems have. My 5 cents is that ODP is BSD license. And odp for specific platform can be deployed only as binary. And customer of that binary simple could not recompile it. And if he will be asked for some debug info he needs to provide something. For that propose run time logging will work. Maxim. > > > > On 12 August 2014 18:00, Wiles, Roger Keith <keith.wiles@windriver.com > <mailto:keith.wiles@windriver.com>> wrote: > > I would like to be able to compile out logging and if logging is > compiled into the code then I need to be able to control logging > (on/off and increase/decrease logging). When logging (or any > feature) is compiled out of the code then all of the logging > statements are removed as in > > // Just made up some logging macro > #ifdef INCLUDE_ODP_LOGGING > extern int global_flag; > #define LOG(flag, …) do { if (flag & global_flag) printf(args); } > while((0)) > #else > #define LOG(flag, ...) do { } while((0) > #endif > > Maybe this is what you are getting at already. > > Thanks > ++Keith > *Keith **Wiles*, Principal Technologist with CTO office, *Wind > River*mobile 972-213-5533 <tel:972-213-5533> > > On Aug 12, 2014, at 10:45 AM, Ola Liljedahl > <ola.liljedahl@linaro.org <mailto:ola.liljedahl@linaro.org>> wrote: > >> If log messages should be compiled-in all the time (at least when >> using the default build configuration), then we need a very >> low-overhead mechanism which can avoid parameter construction and >> even the function call, should logging not be enabled for this >> specific message. >> >> I suggest a simple two-dimensional model where each log message >> is associated with a source indication and a severity level. The >> source indicator identifies the source (e.g. module, block or >> function) of the log message, the severity number identifies some >> sort of severity level (debug, warning, error etc). Then we need >> a control interface to set the log level for a source. >> >> Severity level is a simple scalar, probably with some predefined >> levels (e.g. ODP_LOG_DEBUG etc). >> For the source indication, we need extensibility, can't limit >> this to some predefined set of sources. We don't mind if the >> application also starts using the ODP log mechanism. >> >> Modules in the code should be able to register log sources, it >> could specify a pointer to a (static) integer variable. The log >> manager keeps a list of all log sources and their corresponding >> log variables. >> >> uint32_t odp_queue_loglevel; //Need volatile? >> //register log source "queue" with pointer to odp_queue_loglevel >> >> //report a message to the log >> //put this code in a suitable macro, e.g. >> ODP_LOG(odp_queue_loglevel, ODP_LOG_WARNING, formatstring, >> parameters) >> if (odp_unlikely(odp_queue_loglevel >= ODP_LOG_WARNING)) { >> printf("log message\n", parameters); //Or maybe a call into the >> log manager which can be redirected at runtime >> } >> If logging is disabled for this source and severity level, we >> only get a load, compare and a not taken branch >> >> >> On 11 August 2014 16:09, Mike Holmes <mike.holmes@linaro.org >> <mailto:mike.holmes@linaro.org>> wrote: >> >> We are aiming for hooks that allow ODP to fit in exactly as >> you describe Ola, we don't want to create the final solution, >> every system has its own set up. >> >> I have been involved a lot of postmortem log generation for >> carriers and a few things come to mind that matter. >> >> You need to be able to enable per functional area - say >> classification, crypto so that you don't overwhelm which is >> likely to be a limited ring buffer in memory that traces the >> last few seconds of what was occurring. >> >> It must be possible to comple out some of the most verbose >> logging that just can't be sustained in a real system - but >> that level depends on the system >> >> Generally it is a huge benefit to be able to turn on some >> level of debug whilst in the field rather than send a debug >> build and wait for something to reoccur. >> >> I think we should establish:- >> >> per module hooks that default to printf right now. >> I think we want only five types, ERROR, WARNING, INFO, DBG >> >> examples: >> Error = cannot continue >> warning = out of memory, probably the application can free >> something and re try >> info = allocated crypto session >> trace = entered this function / left this function. >> dbg = not normally needed details. >> >> All of the above are per crypto, classification, buffers etc >> >> >> >> >> On 11 August 2014 09:44, Ola Liljedahl >> <ola.liljedahl@linaro.org <mailto:ola.liljedahl@linaro.org>> >> wrote: >> >> Without a clear definition of what all of these levels >> mean and when a certain level should be used, too much >> granularity does not make sense ("too much choice!"). >> Does the Linux kernel include such a definition we also >> can reuse? >> >> A real managed application would support different log >> levels but also log classes (different modules would >> belong to different log classes but perhaps ODP would be >> a log class in itself), logging would always be >> compiled-in. But I don't think this is what we are aiming >> for. *What are we aiming for?* >> * >> * >> -- Ola >> * >> * >> >> >> On 8 August 2014 12:08, Taras Kondratiuk >> <taras.kondratiuk@linaro.org >> <mailto:taras.kondratiuk@linaro.org>> wrote: >> >> On 08/08/2014 10:41 AM, Santosh Shukla wrote: >> > On 8 August 2014 10:58, Santosh Shukla >> <santosh.shukla@linaro.org >> <mailto:santosh.shukla@linaro.org>> wrote: >> >> On 8 August 2014 04:11, Anders Roxell >> <anders.roxell@linaro.org >> <mailto:anders.roxell@linaro.org>> wrote: >> >>> On 2014-08-05 17:29, Mike Holmes wrote: >> >>>> Signed-off-by: Mike Holmes >> <mike.holmes@linaro.org <mailto:mike.holmes@linaro.org>> >> >>>> --- >> >>>> test/api_test/odp_timer_ping.c | 2 +- >> >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >> >>>> >> >>>> diff --git a/test/api_test/odp_timer_ping.c >> b/test/api_test/odp_timer_ping.c >> >>>> index cd67e0d..ee5f318 100644 >> >>>> --- a/test/api_test/odp_timer_ping.c >> >>>> +++ b/test/api_test/odp_timer_ping.c >> >>>> @@ -374,7 +374,7 @@ int main(int argc >> ODP_UNUSED, char *argv[] ODP_UNUSED) >> >>>> /* Wait for worker threads to exit */ >> >>>> odp_linux_pthread_join(thread_tbl, PING_THRD); >> >>>> >> >>>> - ODP_DBG("ping timer test %s\n", >> (pingarg.result == 0) ? "passed" : "failed"); >> >>>> + ODP_DBG("ping timer test Result:%s\n", >> (pingarg.result == 0) ? "pass" : "fail"); >> >>> >> >>> if we try to fix the output format, shouldn't we >> fix change ODP_DEG to >> >>> printf as well then so we always print out the >> results? >> >>> >> >> >> >> I did not understood, Please elaborate more. Thanks. >> > >> > Per chat discussion, You are right that ODP_DBG >> replaced with printf. >> > However we do >> > need better api like r / printf / odp_print >> > >> > and for such test resuit centric few more api's ( >> as you suggested >> > them which I find quite right) >> > >> > odp_print_pass >> > odp_print_fail >> > >> > >> > Mike, Pl. replace odp_dbg with printf or if you >> choose to work on >> > above proposed api through out the odp test / >> example app would be >> > great. if so, till then we could hold this and >> yours other test >> > patches. Whats you think ..anders/ Mike/ Maxim ?? >> >> In KS2 implementation I'm using prints that mimics >> Linux kernel print >> functions. See below. odp_pr_info() can be used for >> test result print. >> Does it make sense to push these changes to >> linux-generic? >> >> #define ODP_PRINT_LEVEL_CRIT 1 >> #define ODP_PRINT_LEVEL_ERR 2 >> #define ODP_PRINT_LEVEL_WARN 3 >> #define ODP_PRINT_LEVEL_INFO 4 >> #define ODP_PRINT_LEVEL_DBG 5 >> #define ODP_PRINT_LEVEL_VDBG 6 >> #define ODP_PRINT_LEVEL_MAX 7 >> >> #define ODP_PRINT_LEVEL ODP_PRINT_LEVEL_DBG >> >> /** >> * Debug printing macro >> */ >> #ifndef ODP_NO_PRINT >> #define ODP_PRINT(level, fmt, ...) \ >> do { if (level <= ODP_PRINT_LEVEL) \ >> fprintf(stderr, "%s:%d:%s(): " fmt, __FILE__, \ >> __LINE__, __func__, ##__VA_ARGS__); \ >> } while (0) >> #else >> #define ODP_PRINT(level, fmt, ...) >> #endif >> >> #define odp_pr_err(fmt, ...) >> ODP_PRINT(ODP_PRINT_LEVEL_ERR, fmt, ##__VA_ARGS__) >> #define odp_pr_warn(fmt, ...) >> ODP_PRINT(ODP_PRINT_LEVEL_WARN, fmt, ##__VA_ARGS__) >> #define odp_pr_info(fmt, ...) >> ODP_PRINT(ODP_PRINT_LEVEL_INFO, fmt, ##__VA_ARGS__) >> #define odp_pr_dbg(fmt, ...) >> ODP_PRINT(ODP_PRINT_LEVEL_DBG, fmt, ##__VA_ARGS__) >> #define odp_pr_vdbg(fmt, ...) >> ODP_PRINT(ODP_PRINT_LEVEL_VDBG, fmt, ##__VA_ARGS__) >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> <mailto:lng-odp@lists.linaro.org> >> http://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> >> http://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> >> >> -- >> *Mike Holmes* >> Linaro Technical Manager / Lead >> LNG - ODP >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> >> http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp
As a start on debug printing I sent an RFC that allows the logging function to be specified by a callback in the global_init, if that is accepted we can tackle debug levels etc and update the ODP_DBG etc. But in the short term can we accept this patch because it makes what is working today better as part of the push to get a minimal validation framework in place. On 13 August 2014 06:36, Maxim Uvarov <maxim.uvarov@linaro.org> wrote: > On 08/12/2014 10:35 PM, Ola Liljedahl wrote: > >> Always compiled in (but possibly dormant) or compile-time configurable, >> that's the question... >> >> Then one day an already deployed application starts to misbehave and you >> really want to be able to get some info about what is happening before the >> program bellies up. A core dump (for post mortem debugging) is one good >> thing to have. The ability to selectively turn on logging is another >> feature most critical applications and systems have. >> > > My 5 cents is that ODP is BSD license. And odp for specific platform can > be deployed only as binary. And customer of that binary simple could not > recompile it. > And if he will be asked for some debug info he needs to provide something. > For that propose run time logging will work. > > Maxim. > > >> >> >> On 12 August 2014 18:00, Wiles, Roger Keith <keith.wiles@windriver.com >> <mailto:keith.wiles@windriver.com>> wrote: >> >> I would like to be able to compile out logging and if logging is >> compiled into the code then I need to be able to control logging >> (on/off and increase/decrease logging). When logging (or any >> feature) is compiled out of the code then all of the logging >> statements are removed as in >> >> // Just made up some logging macro >> #ifdef INCLUDE_ODP_LOGGING >> extern int global_flag; >> #define LOG(flag, …) do { if (flag & global_flag) printf(args); } >> while((0)) >> #else >> #define LOG(flag, ...) do { } while((0) >> #endif >> >> Maybe this is what you are getting at already. >> >> Thanks >> ++Keith >> *Keith **Wiles*, Principal Technologist with CTO office, *Wind >> River*mobile 972-213-5533 <tel:972-213-5533> >> >> >> On Aug 12, 2014, at 10:45 AM, Ola Liljedahl >> <ola.liljedahl@linaro.org <mailto:ola.liljedahl@linaro.org>> wrote: >> >> If log messages should be compiled-in all the time (at least when >>> using the default build configuration), then we need a very >>> low-overhead mechanism which can avoid parameter construction and >>> even the function call, should logging not be enabled for this >>> specific message. >>> >>> I suggest a simple two-dimensional model where each log message >>> is associated with a source indication and a severity level. The >>> source indicator identifies the source (e.g. module, block or >>> function) of the log message, the severity number identifies some >>> sort of severity level (debug, warning, error etc). Then we need >>> a control interface to set the log level for a source. >>> >>> Severity level is a simple scalar, probably with some predefined >>> levels (e.g. ODP_LOG_DEBUG etc). >>> For the source indication, we need extensibility, can't limit >>> this to some predefined set of sources. We don't mind if the >>> application also starts using the ODP log mechanism. >>> >>> Modules in the code should be able to register log sources, it >>> could specify a pointer to a (static) integer variable. The log >>> manager keeps a list of all log sources and their corresponding >>> log variables. >>> >>> uint32_t odp_queue_loglevel; //Need volatile? >>> //register log source "queue" with pointer to odp_queue_loglevel >>> >>> //report a message to the log >>> //put this code in a suitable macro, e.g. >>> ODP_LOG(odp_queue_loglevel, ODP_LOG_WARNING, formatstring, >>> parameters) >>> if (odp_unlikely(odp_queue_loglevel >= ODP_LOG_WARNING)) { >>> printf("log message\n", parameters); //Or maybe a call into the >>> log manager which can be redirected at runtime >>> } >>> If logging is disabled for this source and severity level, we >>> only get a load, compare and a not taken branch >>> >>> >>> On 11 August 2014 16:09, Mike Holmes <mike.holmes@linaro.org >>> <mailto:mike.holmes@linaro.org>> wrote: >>> >>> We are aiming for hooks that allow ODP to fit in exactly as >>> you describe Ola, we don't want to create the final solution, >>> every system has its own set up. >>> >>> I have been involved a lot of postmortem log generation for >>> carriers and a few things come to mind that matter. >>> >>> You need to be able to enable per functional area - say >>> classification, crypto so that you don't overwhelm which is >>> likely to be a limited ring buffer in memory that traces the >>> last few seconds of what was occurring. >>> >>> It must be possible to comple out some of the most verbose >>> logging that just can't be sustained in a real system - but >>> that level depends on the system >>> >>> Generally it is a huge benefit to be able to turn on some >>> level of debug whilst in the field rather than send a debug >>> build and wait for something to reoccur. >>> >>> I think we should establish:- >>> >>> per module hooks that default to printf right now. >>> I think we want only five types, ERROR, WARNING, INFO, DBG >>> >>> examples: >>> Error = cannot continue >>> warning = out of memory, probably the application can free >>> something and re try >>> info = allocated crypto session >>> trace = entered this function / left this function. >>> dbg = not normally needed details. >>> >>> All of the above are per crypto, classification, buffers etc >>> >>> >>> >>> >>> On 11 August 2014 09:44, Ola Liljedahl >>> <ola.liljedahl@linaro.org <mailto:ola.liljedahl@linaro.org>> >>> >>> wrote: >>> >>> Without a clear definition of what all of these levels >>> mean and when a certain level should be used, too much >>> granularity does not make sense ("too much choice!"). >>> Does the Linux kernel include such a definition we also >>> can reuse? >>> >>> A real managed application would support different log >>> levels but also log classes (different modules would >>> belong to different log classes but perhaps ODP would be >>> a log class in itself), logging would always be >>> compiled-in. But I don't think this is what we are aiming >>> for. *What are we aiming for?* >>> * >>> * >>> -- Ola >>> * >>> >>> * >>> >>> >>> On 8 August 2014 12:08, Taras Kondratiuk >>> <taras.kondratiuk@linaro.org >>> <mailto:taras.kondratiuk@linaro.org>> wrote: >>> >>> On 08/08/2014 10:41 AM, Santosh Shukla wrote: >>> > On 8 August 2014 10:58, Santosh Shukla >>> <santosh.shukla@linaro.org >>> <mailto:santosh.shukla@linaro.org>> wrote: >>> >> On 8 August 2014 04:11, Anders Roxell >>> <anders.roxell@linaro.org >>> <mailto:anders.roxell@linaro.org>> wrote: >>> >>> On 2014-08-05 17:29, Mike Holmes wrote: >>> >>>> Signed-off-by: Mike Holmes >>> <mike.holmes@linaro.org <mailto:mike.holmes@linaro.org>> >>> >>> >>>> --- >>> >>>> test/api_test/odp_timer_ping.c | 2 +- >>> >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>>> >>> >>>> diff --git a/test/api_test/odp_timer_ping.c >>> b/test/api_test/odp_timer_ping.c >>> >>>> index cd67e0d..ee5f318 100644 >>> >>>> --- a/test/api_test/odp_timer_ping.c >>> >>>> +++ b/test/api_test/odp_timer_ping.c >>> >>>> @@ -374,7 +374,7 @@ int main(int argc >>> ODP_UNUSED, char *argv[] ODP_UNUSED) >>> >>>> /* Wait for worker threads to exit */ >>> >>>> odp_linux_pthread_join(thread_tbl, PING_THRD); >>> >>>> >>> >>>> - ODP_DBG("ping timer test %s\n", >>> (pingarg.result == 0) ? "passed" : "failed"); >>> >>>> + ODP_DBG("ping timer test Result:%s\n", >>> (pingarg.result == 0) ? "pass" : "fail"); >>> >>> >>> >>> if we try to fix the output format, shouldn't we >>> fix change ODP_DEG to >>> >>> printf as well then so we always print out the >>> results? >>> >>> >>> >> >>> >> I did not understood, Please elaborate more. Thanks. >>> > >>> > Per chat discussion, You are right that ODP_DBG >>> replaced with printf. >>> > However we do >>> > need better api like r / printf / odp_print >>> > >>> > and for such test resuit centric few more api's ( >>> as you suggested >>> > them which I find quite right) >>> > >>> > odp_print_pass >>> > odp_print_fail >>> > >>> > >>> > Mike, Pl. replace odp_dbg with printf or if you >>> choose to work on >>> > above proposed api through out the odp test / >>> example app would be >>> > great. if so, till then we could hold this and >>> yours other test >>> > patches. Whats you think ..anders/ Mike/ Maxim ?? >>> >>> In KS2 implementation I'm using prints that mimics >>> Linux kernel print >>> functions. See below. odp_pr_info() can be used for >>> test result print. >>> Does it make sense to push these changes to >>> linux-generic? >>> >>> #define ODP_PRINT_LEVEL_CRIT 1 >>> #define ODP_PRINT_LEVEL_ERR 2 >>> #define ODP_PRINT_LEVEL_WARN 3 >>> #define ODP_PRINT_LEVEL_INFO 4 >>> #define ODP_PRINT_LEVEL_DBG 5 >>> #define ODP_PRINT_LEVEL_VDBG 6 >>> #define ODP_PRINT_LEVEL_MAX 7 >>> >>> #define ODP_PRINT_LEVEL ODP_PRINT_LEVEL_DBG >>> >>> /** >>> * Debug printing macro >>> */ >>> #ifndef ODP_NO_PRINT >>> #define ODP_PRINT(level, fmt, ...) \ >>> do { if (level <= ODP_PRINT_LEVEL) \ >>> fprintf(stderr, "%s:%d:%s(): " fmt, __FILE__, \ >>> __LINE__, __func__, ##__VA_ARGS__); \ >>> } while (0) >>> #else >>> #define ODP_PRINT(level, fmt, ...) >>> #endif >>> >>> #define odp_pr_err(fmt, ...) >>> ODP_PRINT(ODP_PRINT_LEVEL_ERR, fmt, ##__VA_ARGS__) >>> #define odp_pr_warn(fmt, ...) >>> ODP_PRINT(ODP_PRINT_LEVEL_WARN, fmt, ##__VA_ARGS__) >>> #define odp_pr_info(fmt, ...) >>> ODP_PRINT(ODP_PRINT_LEVEL_INFO, fmt, ##__VA_ARGS__) >>> #define odp_pr_dbg(fmt, ...) >>> ODP_PRINT(ODP_PRINT_LEVEL_DBG, fmt, ##__VA_ARGS__) >>> #define odp_pr_vdbg(fmt, ...) >>> ODP_PRINT(ODP_PRINT_LEVEL_VDBG, fmt, ##__VA_ARGS__) >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org >>> <mailto:lng-odp@lists.linaro.org> >>> >>> http://lists.linaro.org/mailman/listinfo/lng-odp >>> >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> >>> http://lists.linaro.org/mailman/listinfo/lng-odp >>> >>> >>> >>> >>> -- *Mike Holmes* >>> >>> Linaro Technical Manager / Lead >>> LNG - ODP >>> >>> >>> _______________________________________________ >>> lng-odp mailing list >>> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> >>> http://lists.linaro.org/mailman/listinfo/lng-odp >>> >> >> >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/lng-odp >> > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp >
diff --git a/test/api_test/odp_timer_ping.c b/test/api_test/odp_timer_ping.c index cd67e0d..ee5f318 100644 --- a/test/api_test/odp_timer_ping.c +++ b/test/api_test/odp_timer_ping.c @@ -374,7 +374,7 @@ int main(int argc ODP_UNUSED, char *argv[] ODP_UNUSED) /* Wait for worker threads to exit */ odp_linux_pthread_join(thread_tbl, PING_THRD); - ODP_DBG("ping timer test %s\n", (pingarg.result == 0) ? "passed" : "failed"); + ODP_DBG("ping timer test Result:%s\n", (pingarg.result == 0) ? "pass" : "fail"); printf("ODP ping timer test complete\n\n");
Signed-off-by: Mike Holmes <mike.holmes@linaro.org> --- test/api_test/odp_timer_ping.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)