Hi Pingfan, Philipp,
On 02/14/23 at 04:16pm, Philipp Rudo wrote:
Hi Pingfan,
Hi Coiby,
On Fri, 10 Feb 2023 16:20:27 +0800
Pingfan Liu <piliu(a)redhat.com> wrote:
[...]
For the 64K arm64 kernel installation itself and this patchset, I am
wondering:
1) If we check the NVR of kernel and decide if it's 64K or 4K, it only
works for formal arm64 kernel rpm, right? Some brew build kernel, or
self built kernel won't get handled correctly?
> 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?
2) For Coiby's concern, if thing is easy to handle, we would like to see
4K_c inherit value from 4K_a. Aside from the technical detail, this
looks more natural, but not strong opinion if not easy to implement. While
I personally would suggest we don't need to make it perfectly one time,
just an available one, we can polish it later. Maybe one day we decide
to go in a different way, E.g see Philipp's suggestion or something else?
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.
The idea is still pretty vague, but I think it is worth thinking about
if splitting up the kexec-tools package can help simplifying the
problem.
Yeah, we may need think about simplifying in a whole view. Imagine we
pull a not heavy stuff as before, but now it become harder and harder,
we'd better check if we put the pulling rope on our shoulder, but not
around neck. Just a soft opinion in a view, it's surely not urgent, we
can consider this sometimes.