On 06/02/21 at 01:11am, HAGIO KAZUHITO(萩尾 一仁) wrote:

-----Original Message-----

quoted

On Tue, 1 Jun 2021 10:40:09 +0200 David Hildenbrand [off-list ref] wrote:

quoted

quoted

Thanks, i explained the reason during my last reply.
Andrew has already picked this patch to -mm tree.

Just because it's in Andrews tree doesn't mean it will end up upstream. ;)

Anyhow, no really strong opinion, it's simply unnecessary code churn
that makes bisecting harder without real value IMHO.

I think it's a good change - mem_sections refers to multiple instances
of a mem_section.  Churn is a pain, but that's the price we pay for more
readable code.  And for having screwed it up originally ;)

From a makedumpfile/crash-utility viewpoint, I don't deny kernel improvement
and probably the change will not be hard for them to support, but I'd like
you to remember that the tool users will need to update them for the change.

As VIM user, I can understand Aisheng's feeling on the mem_section
variable which has the same symbol name as its type. Meanwhile it does
cause makedumpfile/crash having to be changed accordingly.

Maybe we can carry it when any essential change is needed in both kernel
and makedumpfile/crash around it.

The situation where we need to update the tools for new kernels is usual, but
there are not many cases that they cannot even start session, and this change

By the way, Kazu, about a case starting session, could you be more specific
or rephrase? I may not get it clearly. Thanks.

will cause it.  Personally I wonder the change is worth forcing users to update
them.

Thanks,
Kazu