From: Dan Williams <dan.j.williams@intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: anshuman.khandual@arm.com, Keith Busch <keith.busch@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux ACPI <linux-acpi@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>,
Greg KH <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH 0/7] ACPI HMAT memory sysfs representation
Date: Mon, 26 Nov 2018 10:08:12 -0800 [thread overview]
Message-ID: <CAPcyv4hVFMvut9+Rq7G41yyKzV072U33YEeHNh160VBr3QW-nw@mail.gmail.com> (raw)
In-Reply-To: <b9962dfa-924f-77f7-a40f-407dd20e9082@intel.com>
On Mon, Nov 26, 2018 at 8:42 AM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 11/23/18 1:13 PM, Dan Williams wrote:
> >> A new system call makes total sense to me. I have the same concern
> >> about the completeness of what's exposed in sysfs, I just don't see a
> >> _route_ to completeness with sysfs itself. Thus, the minimalist
> >> approach as a first step.
> > Outside of platform-firmware-id to Linux-numa-node-id what other
> > userspace API infrastructure does the kernel need to provide? It seems
> > userspace enumeration of memory attributes is fully enabled once the
> > firmware-to-Linux identification is established.
>
> It would be nice not to have each app need to know about each specific
> platform's firmware.
The app wouldn't need to know if it uses a common library. Whether the
library calls into the kernel or not is an implementation detail. If
it is information that only the app cares about and the kernel does
not consume, why have a syscall?
next prev parent reply other threads:[~2018-11-26 18:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-14 22:49 [PATCH 0/7] ACPI HMAT memory sysfs representation Keith Busch
2018-11-16 6:27 ` Anshuman Khandual
2018-11-16 15:51 ` Keith Busch
2018-11-19 1:52 ` Anshuman Khandual
2018-11-16 16:55 ` Dave Hansen
2018-11-19 5:44 ` Anshuman Khandual
2018-11-19 17:37 ` Dave Hansen
2018-11-22 11:52 ` Anshuman Khandual
2018-11-22 18:01 ` Dave Hansen
2018-11-23 6:42 ` Anshuman Khandual
2018-11-23 19:21 ` Dave Hansen
2018-11-23 21:13 ` Dan Williams
2018-11-26 15:52 ` Anshuman Khandual
2018-11-26 16:42 ` Dave Hansen
2018-11-26 18:08 ` Dan Williams [this message]
2018-11-27 10:15 ` Anshuman Khandual
2018-11-27 16:56 ` Dan Williams
2018-11-26 15:38 ` Anshuman Khandual
2018-11-26 17:20 ` Dave Hansen
2018-11-27 9:32 ` Anshuman Khandual
2018-11-22 18:08 ` Dan Williams
2018-11-23 7:10 ` Anshuman Khandual
2018-11-23 17:15 ` Dan Williams
2018-11-27 14:05 ` Anshuman Khandual
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=CAPcyv4hVFMvut9+Rq7G41yyKzV072U33YEeHNh160VBr3QW-nw@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=anshuman.khandual@arm.com \
--cc=dave.hansen@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=keith.busch@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rafael@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).