Re: [GIT PULL] ring-buffer: Updates for 6.11

[Steven Rostedt]

On Fri, 19 Jul 2024 14:05:39 -0400
Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote:

> The whole justification for adding this feature *is* keeping a ring
> buffer around across kernel reboots. If it's just a way to let the
> kernel specify where to place the ring buffer in memory, then what
> is the use-case justifying its integration ?

Yes, but this is broken up into two parts. With this release you have to
know the memory layout and add it explicitly per machine. This takes
quite a bit of knowledge to get right and that's for every individual
system. It's not going to happen for some general application. You have
to know your memory layout and adding this is an advanced operation.
If you are doing this, you should already know what to expect.

When I add the: reserver_mem=12M:4096:trace trace_instance=bootmap@trace
which will allow for a much more generic operation, then yes. I'll be
adding a bunch more documentation and will add the limitations of this.
But that's for the next merge window. This merge window was just to get
the functionality there and a way to test it. But honestly, the
hardcoding of the address is already a high bar and one that even I can
only use on my own machines (that's not going out to chromebooks). For
the more broader audience, I need the reserver_mem option available.
And then I agree that people need to know the limitations of that, as
that *is* a generic operation that can go out into the field.

For now, this is just the infrastructure with a very specific way to
even use it (you need to know the layout of your individual machines).
I don't want to add documentation about rebooting yet, because then the
next merge window is just going to rewrite it.

-- Steve