Re: [RFC PATCH 4/5] unwind: Rename unwind_stacktrace to unwind_user_stacktrace

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 9 Jul 2025 17:41:39 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Wed,  9 Jul 2025 17:25:51 -0400
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> 
> > Rename the unwind_stacktrace structure to unwind_user_stacktrace to make
> > it consistent with the rest of the API.  
> 
> We originally had that name, but decided it was too long. As only the
> deferred unwind uses "unwind_" and it is currently only for user space, do
> we really need to have a 22 character structure name? 17 is already big
> enough.
> 
> And say we make an unwind_kernel_stacktrace()? I doubt we ever would, but
> if we did, it would still use the same structure. There's nothing
> inherently user space here (with maybe the exception of the compat type,
> but still).
> 
> And how is this unique to user space? The kernel can have sframes too.
> 
> Actually, I think we should rename "enum unwind_user_type" to
> "enum unwind_type".
> 
> struct unwind_entry {
> 	enum unwind_type	type;
> 	unsigned long		ip;
> };
> 
> As it is only being used for user space now, but it doesn't mean it can't
> be used for the kernel.
> 
> Heck, there's already work to use sframes in kernel code to replace ORC so
> that architectures like ARM64 can have live kernel patching.

Actually, I'm going to leave everything as is. The "struct unwind_user_*"
is only used internally in the user code and is not part of the API of
the infrastructure. The "struct unwind_stackframe" is used in the API
as a parameter. To me, it makes more sense to keep it short than adding
"user" to it and making all the callbacks have a longer name.

I know your patch 5 exposes more, but we'll deal with that when the
time comes.

-- Steve