Re: [PATCH v3 2/2] pstore/ramoops: Add ramoops.mem_name= command line option

From: Ard Biesheuvel
Date: Thu Jun 13 2024 - 10:07:08 EST


On Thu, 13 Jun 2024 at 15:26, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> On Thu, 13 Jun 2024 08:11:48 +0200
> Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> > >
> > > I've added one more comment to v5, with that fixed I can take this.
> > >
> >
> > So how is this supposed to work wrt to the rigid 'no user visible
> > regressions' rule, given that this whole thing is a best effort thing
>
> This has nothing to do with user space. The kernel command line has
> broken in the past. If you update the kernel, you can update the
> command line. There's no "no user visible regressions" rule. It's
> "Don't break user space". This has nothing to do with user space.
>
> > to begin with. This needs at least a huge disclaimer that this rule
> > does not apply, and if this works today, there is no guarantee that it
> > will keep working on newer kernels. Otherwise, you will be making the
> > job of the people who work on the boot code significantly more
> > difficult. And even then, I wonder whether Linus and #regzcop are
> > going to honour such a disclaimer.
>
> Again, this has nothing to do with user space. The rule Linus talks
> about is breaking user space. This is about kernel debugging. Something
> *completely different*!
>
> >
> > So this belongs downstream, unless some guarantees can be provided
> > that this functionality is exempt from the usual regression policies.
>
> I disagree. kexec/kdump also has the same issues.
>

Fair enough. As long as it is documented that there is no guarantee
that this will keep working over a kernel upgrade, then I have no
objections.