On 15/03/2026 11:09, Steven Rostedt wrote: > On Fri, 13 Mar 2026 17:57:35 -0300 > [...] >> So, are you suggesting to use the ftrace infrastructure in the >> pstore/ftrace? Well, seeing how mature the ftrace infra is with regards >> the persistent ring buffer, I'd say pstore/ftrace+ramoops gets useless >> now heh > > The persistent ring buffer only works when the memory is reliably > consistent between soft reboots. It doesn't work for any other pstore > interface. Thus, if you can rely on normal ram being available across > reboots, then use ftrace. If not, then you have to use pstore. Hence, > it doesn't make pstore useless. > > I would not use the ftrace scratchpad for pstore, as if that works, > then just use ftrace ;-) > >> >> The usage then for pstore/ftrace would be more with other backends, >> really low memory cases like ERST or UEFI, for example, in embedded >> maybe. And in this case, saving the full modules name table + offsets >> could incur some precious memory consumption and/or performance impact. >> Or maybe I'm talking nonsense and this would be quite OK ... guess worth >> taking a look. > > Exactly (I wrote the above before reading this paragraph!)
Perfect, thanks for confirming. I think the idea of factoring KASLR on pstore/ftrace (in a simple way) is then valid ... let's see others' opinions =) Cheers, Guilherme
