[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180504101631.GB9377@pd.tnic>
Date: Fri, 4 May 2018 12:16:31 +0200
From: Borislav Petkov <bp@...e.de>
To: Baoquan He <bhe@...hat.com>
Cc: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
robh+dt@...nel.org, dan.j.williams@...el.com,
nicolas.pitre@...aro.org, josh@...htriplett.org,
Thomas Gleixner <tglx@...utronix.de>,
Brijesh Singh <brijesh.singh@....com>,
Jérôme Glisse <jglisse@...hat.com>,
Tom Lendacky <thomas.lendacky@....com>,
Wei Yang <richard.weiyang@...il.com>
Subject: Re: [PATCH v3 2/3] resource: add walk_system_ram_res_rev()
On Thu, Apr 26, 2018 at 09:22:04PM +0800, Baoquan He wrote:
> I noticed maintainers merged patches with this Message-ID, could you
> tell how to get this Message-ID?
https://en.wikipedia.org/wiki/Message-ID
> This is not a thing that one is top down, the other is bottom up. For
> us, they might be so different on details of code, for customers, they
> just think them as a same thing. They may say I just get a new machine,
> and still do kexec loading, why these top-down, bottom-up things come
> up.
So if I read the above correctly, it doesn't matter whether top-down or
bottom-up.
> And this is not causing code churn. You can see that by replacing
> pointer operation with list_head, code in kernel/resource.c related to
> child list iteration is much easier to read,
Now *this* is starting to sound like some reason "why". If it is better
readability, then say so in the commit message.
It still doesn't justify adding walk_system_ram_res_rev() though.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
Powered by blists - more mailing lists