From: Borislav Petkov <bp@alien8.de>
To: Toshi Kani <toshi.kani@hpe.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-arch@vger.kernel.org, Linux MM <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH 01/11] resource: Add System RAM resource type
Date: Wed, 23 Dec 2015 15:23:49 +0100 [thread overview]
Message-ID: <20151223142349.GG30213@pd.tnic> (raw)
In-Reply-To: <1450814672.10450.83.camel@hpe.com>
On Tue, Dec 22, 2015 at 01:04:32PM -0700, Toshi Kani wrote:
> The above example referred the case with distros, not with the upstream.
> That is, one writes a new loadable module and makes it available in the
> upstream. Then s/he makes it work on a distro used by the customers, but
> may or may not be able to change the distro kernel/drivers used by the
> customers.
Huh?
Still sounds bogus to me. Distro kernels get stuff backported to them
all the time to accomodate new features, hw support.
Your new interfaces will be used only in new code so if distros want
it, they can either backport the new kernel interfaces or use an older
version with the strings.
> I agree that we can add new interfaces with the type check. This 'type'
> may need some clarification since it is an assigned type, which is
> different from I/O resource type. That is, "System RAM" is an I/O resource
> type (i.e. IORESOURCE_SYSTEM_RAM), but "Crash kernel" is an assigned type
> to a particular range of System RAM. A range may be associated with
> multiple names, so as multiple assigned types. For lack of a better idea,
> I may call it 'assign_type'. I am open for a better name.
Or assigned_type or named_type or so...
I think we should avoid calling it "type" completely in order to avoid
confusion with the IORESOURCE_* types and call it "desc" or so to mean
description, sort, etc, because the name is also a description of the
resource to a certain degree...
> OK, I will try to convert the existing callers with the new interfaces.
Either that or add the new interfaces, use them in your use case, add
big fat comments explaining that people should use those from now on
when searching by name and add a check to checkpatch to catch future
mis-uses...
Thanks!
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-12-23 14:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-14 23:37 Toshi Kani
2015-12-14 23:37 ` [PATCH 02/11] resource: make resource flags handled properly Toshi Kani
2015-12-14 23:37 ` [PATCH 03/11] x86/e820: Set IORESOURCE_SYSTEM_RAM to System RAM Toshi Kani
2015-12-14 23:37 ` [PATCH 04/11] arch: " Toshi Kani
2015-12-14 23:37 ` [PATCH 05/11] xen: " Toshi Kani
2015-12-14 23:37 ` [PATCH 06/11] kexec: " Toshi Kani
2015-12-14 23:37 ` [PATCH 07/11] memory-hotplug: " Toshi Kani
2015-12-14 23:37 ` [PATCH 08/11] memremap: Change region_intersects() to use System RAM type Toshi Kani
2015-12-14 23:37 ` [PATCH 09/11] resource: Change walk_system_ram " Toshi Kani
2015-12-14 23:37 ` [PATCH 10/11] arm/samsung: Change s3c_pm_run_res() " Toshi Kani
2015-12-15 0:19 ` Krzysztof Kozlowski
2015-12-14 23:37 ` [PATCH 11/11] ACPI/EINJ: Allow memory error injection to NVDIMM Toshi Kani
2015-12-16 12:26 ` [PATCH 01/11] resource: Add System RAM resource type Borislav Petkov
2015-12-16 15:44 ` Toshi Kani
2015-12-16 15:49 ` Borislav Petkov
2015-12-16 16:35 ` Toshi Kani
2015-12-16 17:45 ` Borislav Petkov
2015-12-16 17:52 ` Dan Williams
2015-12-16 18:17 ` Borislav Petkov
2015-12-16 18:57 ` Dan Williams
2015-12-16 19:16 ` Borislav Petkov
2015-12-16 21:52 ` Toshi Kani
2015-12-22 11:34 ` Borislav Petkov
2015-12-22 20:04 ` Toshi Kani
2015-12-23 14:23 ` Borislav Petkov [this message]
2015-12-24 2:23 ` Toshi Kani
2015-12-24 17:08 ` Toshi Kani
2015-12-24 19:58 ` Borislav Petkov
2015-12-24 21:37 ` Toshi Kani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151223142349.GG30213@pd.tnic \
--to=bp@alien8.de \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rafael.j.wysocki@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=toshi.kani@hpe.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox