# 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 15:14:59 
- List: linux-trace-kernel
- Page: https://ratatoskr.run/linux-trace-kernel/2025/07/3127806
- Thread: https://ratatoskr.run/linux-trace-kernel/2025/07/3124692/t.md

```text
On 2025-07-09 10:29, Steven Rostedt wrote:
> On Wed, 9 Jul 2025 10:10:30 -0400
> Mathieu Desnoyers [ref] wrote:
>
>> 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.
>
> The changes you are suggesting is added info if an architecture needs
> it. That is easy to do. All you need is to add an extra field in the
> state structure and the architectures that need it can use it, and the
> rest can ignore it.
>
> Again, I'm not worried about it. If you want to send me a patch, feel
> free, but I'm not doing this extra work, until I see a real problem.
OK, I'll do it. As I look into the existing state, the priority order
appears to be incorrect on compat mode: if we have both compat mode and
sframe available, COMPAT_FP is preferred. I think we want to favor using
sframe first. But then if you select "sframe" in start(), then you don't
have the "compat state" information for the compat-fp fallback.

So the "type" logic is all intermingled between "fp vs sframe" and
"compat vs non-compat" there. My changes will clean this up.

Thanks,

Mathieu

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