Hi Pingfan,
On Thu, 16 Feb 2023 13:46:30 +0800
Pingfan Liu <piliu(a)redhat.com> wrote:
Hi Philipp,
Thanks for your insight.
On Tue, Feb 14, 2023 at 11:17 PM Philipp Rudo <prudo(a)redhat.com> wrote:
>
> Hi Pingfan,
> Hi Coiby,
>
>
> On Fri, 10 Feb 2023 16:20:27 +0800
> Pingfan Liu <piliu(a)redhat.com> wrote:
>
> [...]
>
> > Here, if the installed kernel is different from the running kernel, it
> > just uses the default recommended "crashkernel=".
> >
> > But when discussion with Coiby off-list, he showed his concerns:
> > -1. whether it is suitable to use the default recommended 64K value if
> > a user has a user defined value for 4K kernel
> > -2. if installing a series kernel: 4K_a, 64K_b, 4K_c, and in kernel
> > '4K_a ', the user has specify his prefered "crashkernel=",
and in
> > 64K_b, during the installation of 4K_c kernel, this patch can not
> > inherit the user preferred value for 4K_a.
> > (where the naming 4K_a/ 4K_b/ 64K_c means #pagesize_#instance, i.e
> > three instances a, b and c.)
> >
> > For the time being, I have no good idea about it. Any suggestions about it?
>
> That's a valid point...
>
> The way I see it we need to find a way to (1) split the problem into
> smaller, easier digestible chunks and (2) define a way the user tells
> us to manage the crashkernel value and thus allows us to ignore any
> changes made manually.
>
> The idea I'm having is that we split the crashkernel default value and
> the update routines from the main kexec-tools into a separate package.
> Ideally we even find a way to define different versions of that package
> that depend on a specific kernel version/variant. When a user installs
> this package he/she also agrees that we are managing the crashkernel
> parameter and allows us to overwrite any changes made by the user.
>
I guess you suggest kexec-tools.aarch64_4K and kexec-tools.aarch64_64K.
Not exactly. My idea was to split the kexec-tools into two packages,
i.e. the base kexec-tools containing most of todays package and
kexec-tools-crashkernel-default only handling the default values.
kexec-tools-crsahkernel-default could then be variant specific (if that
works).
But shall we consider the case in which a user needs two kernel
variants? If it is true, things may not easy.
Yeah, this would be a very nasty corner case with my suggestion...
Thanks
Philipp