>-----Original Message-----
>From: Jan Kiszka <jan.kis...@siemens.com>
>Sent: Monday, November 29, 2021 3:58 PM
>To: Chen, Hongzhan <hongzhan.c...@intel.com>; xenomai@xenomai.org
>Subject: Re: [PATCH v2 2/2] cobalt/trace: dovetail: remove TODO and return
>-ENOSYS for unportable features
>
>On 29.11.21 02:03, Hongzhan Chen via Xenomai wrote:
>> Some of the features are unportable because ftrace does not
>> provide equivalent functionality to the ipipe tracer (namely double
>> buffering so that you can continue to record in flight-recorder mode
>> while a previous recording remains available).
>>
>> We remove TODOs to pass allyesconfig make.
>>
>> Signed-off-by: Hongzhan Chen <hongzhan.c...@intel.com>
>> ---
>> include/cobalt/kernel/dovetail/pipeline/trace.h | 15 +++++----------
>> 1 file changed, 5 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/cobalt/kernel/dovetail/pipeline/trace.h
>> b/include/cobalt/kernel/dovetail/pipeline/trace.h
>> index 479191e0e..c7df3be79 100644
>> --- a/include/cobalt/kernel/dovetail/pipeline/trace.h
>> +++ b/include/cobalt/kernel/dovetail/pipeline/trace.h
>> @@ -27,20 +27,17 @@
>>
>> static inline int xntrace_max_begin(unsigned long v)
>> {
>> - TODO();
>> - return 0;
>> + return -ENOSYS;
>> }
>>
>> static inline int xntrace_max_end(unsigned long v)
>> {
>> - TODO();
>> - return 0;
>> + return -ENOSYS;
>> }
>>
>> static inline int xntrace_max_reset(void)
>> {
>> - TODO();
>> - return 0;
>> + return -ENOSYS;
>> }
>>
>> static inline int xntrace_user_start(void)
>> @@ -96,14 +93,12 @@ static inline int xntrace_tick(unsigned long
>> delay_ticks) /* ns */
>>
>> static inline int xntrace_panic_freeze(void)
>> {
>> - TODO();
>> - return 0;
>> + return -ENOSYS;
>> }
>>
>> static inline int xntrace_panic_dump(void)
>> {
>> - TODO();
>> - return 0;
>> + return -ENOSYS;
>> }
>>
>
>Looking at these two panic "abstractions": They are only called by
>dovetail-specific handle_oob_trap_entry. There, we should rather use
>kernel native tracing functions to stop and dump a trace.
I found that in EVL implementation of handle_oob_trap_entry ,especially
for note_trap implementation , it have not implemented stop and dump
a trace and just try to printk warning (please refer to kernel/evl/thread.c of
evl branch).
handle_oob_trap_entry would try to demote current stage and leave in-band to
handle
following thing. If we do native thing here, is there duplicated thing happen?
Regards
Hongzhan Chen
>
>And for I-pipe, we can fold the two abstractions into handle_exception()
>there as well.
>
>Jan
>
>--
>Siemens AG, T RDA IOT
>Corporate Competence Center Embedded Linux
>
>
>
>
