[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPcyv4h+n51Z2hskP2+PX44OB47OQwrKcqVr3nrvMzG++qjC+w@mail.gmail.com>
Date: Wed, 16 Dec 2015 09:52:37 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Toshi Kani <toshi.kani@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-arch@...r.kernel.org, Linux MM <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH 01/11] resource: Add System RAM resource type
On Wed, Dec 16, 2015 at 9:45 AM, Borislav Petkov <bp@...en8.de> wrote:
> On Wed, Dec 16, 2015 at 09:35:59AM -0700, Toshi Kani wrote:
>> We do not have enough bits left to cover any potential future use-cases
>> with other strings if we are going to get rid of strcmp() completely.
>
> Look at the examples I gave. I'm talking about having an additional
> identifier which can be a number and not a bit.
>
>> Since the searches from crash and kexec are one-time thing, and einj
>> is a R&D tool, I think we can leave the strcmp() check for these
>> special cases, and keep the interface flexible with any strings.
>
> I don't think using strings is anywhere close to flexible. If at all, it
> is an odd use case which shouldnt've been allowed in in the first place.
>
It's possible that as far as the resource table is concerned the
resource type might just be "reserved". It may not be until after a
driver loads that we discover the memory range type. The identifying
string is driver specific at that point.
All this to say that with strcmp we can search for any custom type .
Otherwise I think we're looking at updating the request_region()
interface to take a type parameter. That makes strcmp capability more
attractive compared to updating a potentially large number of
request_region() call sites.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists