[Feature Request] distinguish traceTASK_SWITCHED_IN

[KammutierSpule]

traceTASK_SWITCHED_IN is used on multiple places in task.c

it is called before the scheduler started or it can be called inside an ISR.

That doesn't help to optimize on some uses / implementation to know if is inside an ISR or not.

Also, xCoreID is available on some case and not on others.
It may help to uniformize it somehow.

[aggarg]

it is called before the scheduler started or it can be called inside an ISR.

It is called at 2 places:

1. While starting the scheduler - https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/tasks.c#L3756.
2. While switching tasks in vTaskSwitchContext - https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/tasks.c#L5168.

Would you please elaborate on the problem you are facing?

Also, xCoreID is available on some case and not on others.

xCoreID is available if you are using SMP (i.e. configNUMBER_OF_CORES ia greater than 1). If you are not using SMP, there is only one core and hence xCoreID is not needed. Again, would you please share the problem you are facing?

[KammutierSpule]

it is called before the scheduler started or it can be called inside an ISR.

It is called at 2 places

OK was giving a closer look and seems both cases are inside a critical section, which is ok for me.

Also, xCoreID is available on some case and not on others.

xCoreID is available if you are using SMP (i.e. configNUMBER_OF_CORES ia greater than 1). If you are not using SMP, there is only one core and hence xCoreID is not needed. Again, would you please share the problem you are facing?

What I mean is that, considering cores >1,
on void vTaskSwitchContext( BaseType_t xCoreID ) function you have access to this xCoreID,
but on vTaskStartScheduler there is no xCoreID

Honestly, I don't know if that makes sense on vTaskStartScheduler to know the coreID.

Ideally, I was looking that the core ID was passed to the macro:
traceTASK_SWITCHED_IN(xCoreID);

or better:
traceTASK_SWITCHED_IN(pxCurrentTCB, xCoreID);

as right now, using traceTASK_SWITCHED_IN( macro, we should assume that there is available one variable called "pxCurrentTCB"

[aggarg]

Ideally, I was looking that the core ID was passed to the macro:
traceTASK_SWITCHED_IN(xCoreID);
or better:
traceTASK_SWITCHED_IN(pxCurrentTCB, xCoreID);

I agree that it is a good suggestion. The problem is that it is not backward compatible and will break existing tracers. You can assume that pxCurrentTCB is present and use configNUMBER_OF_CORES to decide to use xCoreID.

[KammutierSpule]

You can assume that pxCurrentTCB is present and use configNUMBER_OF_CORES to decide to use xCoreID.

That backs to my original post,
"use configNUMBER_OF_CORES to decide to use xCoreID", on vTaskStartScheduler there is no 'xCoreID' so we can't implement same way the traceTASK_SWITCHED_IN as for 'vTaskSwitchContext'. The only compatible way would be to make (another, on 'vTaskSwitchContext') request to get core ID, which will add more overhead code on 'vTaskSwitchContext'.

[aggarg]

The only compatible way would be to make (another, on 'vTaskSwitchContext') request to get core ID, which will add more overhead code on 'vTaskSwitchContext'.

You are correct. While we could remove traceTASK_SWITCHED_IN from vTaskStartScheduler since we now have traceSTARTING_SCHEDULER, doing so might break existing tracers. The only option seems to accept the performance overhead of one additional get core ID call as you suggested.