From: Dan Williams <dan.j.williams@intel.com>
To: Linda Knippers <linda.knippers@hpe.com>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>
Subject: Re: [PATCH 1/3] Allow all supported HPE DSM functions to be called
Date: Thu, 16 Feb 2017 13:07:27 -0800 [thread overview]
Message-ID: <CAPcyv4jdDrZzzVx5+uSb2tHg4MvqWeyzMXunq3F3L6dzYaBOyw@mail.gmail.com> (raw)
In-Reply-To: <CAPcyv4gpmz-1E23pHdoy49k+CWXBb-m-7PRbBOb18xTgyhcbUw@mail.gmail.com>
On Thu, Feb 16, 2017 at 12:48 PM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Thu, Feb 16, 2017 at 12:13 PM, Linda Knippers <linda.knippers@hpe.com> wrote:
[..]
>> I am fairly certain that for production use we wouldn't expect management
>> tools to use more than one DSM family at a time. Tools using DSMs
>> from one family wouldn't switch to using a new family for one operation
>> and then switch back for another operation.
>
> If the kernel makes it safe I don't see why this is a blocker,
> especially if the goal is to reduce interface proliferation over time.
In fact, we can make it even simpler than dynamically changing family,
just have ND_IOCTL_VENDOR always route to uuid
""4309ac30-0d11-11e4-9191-0800200c9a66" and function number 9. Then
that becomes the de facto method for Linux to issue a vendor-specific
command for any DIMM.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
next prev parent reply other threads:[~2017-02-16 21:07 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 16:27 [PATCH 0/3] apci, nfit: DSM improvements Linda Knippers
2017-02-13 16:27 ` [PATCH 1/3] Allow all supported HPE DSM functions to be called Linda Knippers
2017-02-13 17:28 ` Dan Williams
2017-02-13 18:17 ` Linda Knippers
2017-02-13 18:30 ` Dan Williams
2017-02-15 23:19 ` Linda Knippers
2017-02-16 0:29 ` Dan Williams
2017-02-16 0:45 ` Linda Knippers
2017-02-16 2:03 ` Dan Williams
2017-02-16 18:51 ` Linda Knippers
2017-02-16 19:35 ` Dan Williams
2017-02-16 20:13 ` Linda Knippers
2017-02-16 20:48 ` Dan Williams
2017-02-16 21:07 ` Dan Williams [this message]
2017-02-16 22:40 ` Linda Knippers
2017-02-16 22:43 ` Dan Williams
2017-02-16 22:47 ` Linda Knippers
2017-02-16 22:49 ` Dan Williams
2017-02-16 22:52 ` Linda Knippers
2017-02-16 22:33 ` Linda Knippers
2017-02-19 16:28 ` Boaz Harrosh
2017-02-13 16:27 ` [PATCH 2/3] Allow specifying a default DSM family Linda Knippers
2017-02-13 16:27 ` [PATCH 3/3] Remove unnecessary newline Linda Knippers
2017-02-13 17:32 ` Dan Williams
2017-02-13 18:02 ` Linda Knippers
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=CAPcyv4jdDrZzzVx5+uSb2tHg4MvqWeyzMXunq3F3L6dzYaBOyw@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=linda.knippers@hpe.com \
--cc=linux-nvdimm@lists.01.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.