[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151216181712.GJ29775@pd.tnic>
Date: Wed, 16 Dec 2015 19:17:12 +0100
From: Borislav Petkov <bp@...en8.de>
To: Dan Williams <dan.j.williams@...el.com>
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 09:52:37AM -0800, Dan Williams wrote:
> 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.
So how many types are we talking about here? Because I don't find a whole lot:
$ git grep -E "(walk_iomem_res|find_next_iomem_res|region_intersects)" -- *.c | grep -Eo '\".*\"'
"GART"
"ACPI Tables"
"ACPI Non-volatile Storage"
"Crash kernel"
"System RAM"
"System RAM"
"System RAM"
An int type could contain 2^32 different types.
> 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.
Right, but I don't think that @name param to request_region() was ever
meant to be mis-used as a matching attribute when iterating over the
resource types.
Now, imagine you have to do this pretty often. Which is faster: a
strcmp() or an int comparison...?
Even if this cannot be changed easily/in one go, maybe we should at
least think about starting doing it right so that the strcmp() "fun" is
phased out gradually...
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
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