# Re: \[PATCH v8 06/12\] unwind\_user/sframe: Wire up unwind\_user to sframe

- From: Mathieu Desnoyers \<mathieu.desnoyers@efficios.com\>
- Date: 2025-07-09 14:10:36 
- List: linux-trace-kernel
- Page: https://ratatoskr.run/linux-trace-kernel/2025/07/3127665
- Thread: https://ratatoskr.run/linux-trace-kernel/2025/07/3124692/t.md

```text
On 2025-07-09 10:06, Steven Rostedt wrote:
> On Wed, 9 Jul 2025 09:51:09 -0400
> Mathieu Desnoyers [ref] wrote:
>
>> One use-case for giving the "current_type" to iteration callers is to
>> let end users know whether they should trust the frame info. If it
>> comes from sframe, then it should be pretty solid. However, if it comes
>> from frame pointers used as a fallback on a system that omits frame
>> pointers, the user should consider the resulting data with a high level
>> of skepticism.
>
> That would be in the trace sent to the callback. We could add something
> like the '?' if it's not trusted.
>
> But for now, until we have a use case that we are implementing, I want
> to keep this simple, otherwise it will never get done. I don't want to
> add features for hypothetical scenarios.
>
> Currently, the traceback is just an array of addresses. But this could
> change in the future. What we are discussing right now is the internal
> functionality of the user unwind code where I have made most of theses
> functions static.
>
> The only external functions that get called during the iteration is the
> architecture specific code. If that code needs to know the difference
> between sframes and frame pointers then we can modify it, but until
> then, I rather keep this as is.

Indeed it's only kernel internal API, but this is API that will be
expected by each architecture supporting unwind_user. Changing
this later on will cause a lot of friction and cross-architecture churn
compared to doing it right in the first place.

Thanks,

Mathieu

>
> Jens, is there something that the architecture code needs now? If so,
> then lets fix it, otherwise lets do it when there is something. This
> isn't user API, it can change in the future.
>
> -- Steve


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
```