On 2/17/25 13:19, Johannes Berg wrote:
> On Mon, 2025-02-17 at 12:44 +0200, Eugen Hristev wrote:
>>
>> At this moment going through devcoredump is not something that impacts
>> the idea of the implementation.
>
> Yeah. I don't think it _should_ go through it at all.
>
>> The whole reason of go
On Mon, 2025-02-17 at 13:39 +0200, Eugen Hristev wrote:
>
> On 2/17/25 13:19, Johannes Berg wrote:
> > On Mon, 2025-02-17 at 12:44 +0200, Eugen Hristev wrote:
> > >
> > > At this moment going through devcoredump is not something that impacts
> > > the idea of the implementation.
> >
> > Yeah. I
On Mon, 2025-02-17 at 12:44 +0200, Eugen Hristev wrote:
>
> At this moment going through devcoredump is not something that impacts
> the idea of the implementation.
Yeah. I don't think it _should_ go through it at all.
> The whole reason of going through it (because things work without it as
> w
On 2/17/25 12:23, Johannes Berg wrote:
> On Mon, 2025-02-17 at 12:16 +0200, Eugen Hristev wrote:
>
>> This series comes as an RFC proposed solution to enhance pstore and
>> devcoredump with the following functionality:
>
> ...
>
>> This patch series attempts to solve this by reusing existing
On Mon, 2025-02-17 at 12:16 +0200, Eugen Hristev wrote:
> This series comes as an RFC proposed solution to enhance pstore and
> devcoredump with the following functionality:
...
> This patch series attempts to solve this by reusing existing
> infrastructure in pstore and devcoredump, and provide
Hello,
This series comes as an RFC proposed solution to enhance pstore and
devcoredump with the following functionality:
It is interesting to mark specific memory regions in the kernel
as core areas, such that in the even of a cataclysmic event like
panic, deadlock, hardware fault, those areas can
