From: Christoph Hellwig <hch@lst.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
Boaz Harrosh <boaz@plexistor.com>, Neil Brown <neilb@suse.de>,
Greg KH <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>, Jens Axboe <axboe@fb.com>,
"H. Peter Anvin" <hpa@zytor.com>, Christoph Hellwig <hch@lst.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
Date: Mon, 20 Apr 2015 14:53:38 +0200 [thread overview]
Message-ID: <20150420125338.GA5463@lst.de> (raw)
In-Reply-To: <CAPcyv4g8wAzWq34onfYKreoh+qEv6KWzaAmAmGnvW5KhoB07xA@mail.gmail.com>
[I haven't much time to look through the patches, so only high level
hand wavey comments for now, sorry..]
On Mon, Apr 20, 2015 at 01:14:42AM -0700, Dan Williams wrote:
> > So why on earth is this whole concept and the naming itself
> > ('drivers/block/nd/' stands for 'NFIT Defined', apparently) revolving
> > around a specific 'firmware' mindset and revolving around specific,
> > weirdly named, overly complicated looking firmware interfaces that
> > come with their own new weird glossary??
>
> There's only three core properties of NVDIMMs that this implementation
> cares about.
>
> 1/ directly mapped interleaved persistent memory (PMEM)
> 2/ indirect mmio aperture accessed (windowed) persistent memory (BLK)
> 3/ the possibility that those 2 access modes may alias the same
> on-media addresses
>
> Most of complexity of the implementation is dealing with aspect 3, but
> that complexity can and is bypassed in places.
>
> > Firmware might be a discovery method - or not. A non-volatile device
> > might be e820 enumerated, or PCI discovered - potentially with all
> > discovery handled by the driver.
>
> PCI attached non-volatile memory is NVMe. ND is handling address
> ranges that support direct cpu load store.
But those can't be attached in all kinds of different ways. It's not like
this is a new thing - they've been used in Storage OEM systems for a long
time, both on Intel platforms and other CPUs.
And the current pmem.c can also handle cases like a PCI card exposing
a large mmio region that can be used as persistent memory.
So a big vote from me into namving this the pmem subsystem and trying
to have names not too tied to one specific firmware interface. Once
I'll go through this in more detail I'll comment more.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>,
"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
Boaz Harrosh <boaz@plexistor.com>, Neil Brown <neilb@suse.de>,
Greg KH <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>, Jens Axboe <axboe@fb.com>,
"H. Peter Anvin" <hpa@zytor.com>, Christoph Hellwig <hch@lst.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
Date: Mon, 20 Apr 2015 14:53:38 +0200 [thread overview]
Message-ID: <20150420125338.GA5463@lst.de> (raw)
In-Reply-To: <CAPcyv4g8wAzWq34onfYKreoh+qEv6KWzaAmAmGnvW5KhoB07xA@mail.gmail.com>
[I haven't much time to look through the patches, so only high level
hand wavey comments for now, sorry..]
On Mon, Apr 20, 2015 at 01:14:42AM -0700, Dan Williams wrote:
> > So why on earth is this whole concept and the naming itself
> > ('drivers/block/nd/' stands for 'NFIT Defined', apparently) revolving
> > around a specific 'firmware' mindset and revolving around specific,
> > weirdly named, overly complicated looking firmware interfaces that
> > come with their own new weird glossary??
>
> There's only three core properties of NVDIMMs that this implementation
> cares about.
>
> 1/ directly mapped interleaved persistent memory (PMEM)
> 2/ indirect mmio aperture accessed (windowed) persistent memory (BLK)
> 3/ the possibility that those 2 access modes may alias the same
> on-media addresses
>
> Most of complexity of the implementation is dealing with aspect 3, but
> that complexity can and is bypassed in places.
>
> > Firmware might be a discovery method - or not. A non-volatile device
> > might be e820 enumerated, or PCI discovered - potentially with all
> > discovery handled by the driver.
>
> PCI attached non-volatile memory is NVMe. ND is handling address
> ranges that support direct cpu load store.
But those can't be attached in all kinds of different ways. It's not like
this is a new thing - they've been used in Storage OEM systems for a long
time, both on Intel platforms and other CPUs.
And the current pmem.c can also handle cases like a PCI card exposing
a large mmio region that can be used as persistent memory.
So a big vote from me into namving this the pmem subsystem and trying
to have names not too tied to one specific firmware interface. Once
I'll go through this in more detail I'll comment more.
next prev parent reply other threads:[~2015-04-20 12:53 UTC|newest]
Thread overview: 160+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-18 1:35 [PATCH 00/21] ND: NFIT-Defined / NVDIMM Subsystem Dan Williams
2015-04-18 1:35 ` Dan Williams
2015-04-18 1:35 ` [PATCH 01/21] e820, efi: add ACPI 6.0 persistent memory types Dan Williams
2015-04-18 1:35 ` Dan Williams
2015-04-18 4:41 ` Andy Lutomirski
2015-04-18 4:41 ` Andy Lutomirski
2015-04-19 7:46 ` Boaz Harrosh
2015-04-19 7:46 ` Boaz Harrosh
2015-04-20 17:08 ` Dan Williams
2015-04-20 17:08 ` Dan Williams
2015-04-28 12:46 ` [Linux-nvdimm] " Christoph Hellwig
2015-04-28 19:20 ` Dan Williams
2015-04-18 1:35 ` [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem Dan Williams
2015-04-18 1:35 ` Dan Williams
2015-04-20 7:06 ` Ingo Molnar
2015-04-20 7:06 ` Ingo Molnar
2015-04-20 8:14 ` Dan Williams
2015-04-20 8:14 ` Dan Williams
2015-04-20 12:53 ` Christoph Hellwig [this message]
2015-04-20 12:53 ` Christoph Hellwig
2015-04-20 15:57 ` Dan Williams
2015-04-20 15:57 ` Dan Williams
2015-04-21 13:38 ` Dan Williams
2015-04-21 13:38 ` Dan Williams
2015-04-28 12:48 ` [Linux-nvdimm] " Christoph Hellwig
2015-04-18 1:35 ` [PATCH 03/21] nd_acpi: initial core implementation and nfit skeleton Dan Williams
2015-04-18 1:35 ` Dan Williams
2015-04-18 19:41 ` Paul Bolle
2015-04-18 19:41 ` Paul Bolle
2015-04-19 19:12 ` Rafael J. Wysocki
2015-04-19 19:12 ` Rafael J. Wysocki
2015-04-28 12:53 ` [Linux-nvdimm] " Christoph Hellwig
2015-04-28 19:21 ` Dan Williams
2015-04-18 1:35 ` [PATCH 04/21] nd: create an 'nd_bus' from an 'nfit_desc' Dan Williams
2015-04-18 1:35 ` Dan Williams
2015-04-21 19:35 ` [Linux-nvdimm] " Toshi Kani
2015-04-21 19:35 ` Toshi Kani
2015-04-21 19:58 ` Dan Williams
2015-04-21 19:58 ` Dan Williams
2015-04-21 19:55 ` Toshi Kani
2015-04-21 19:55 ` Toshi Kani
2015-04-21 20:35 ` Dan Williams
2015-04-21 20:35 ` Dan Williams
2015-04-21 20:32 ` Toshi Kani
2015-04-21 20:32 ` Toshi Kani
2015-04-22 16:39 ` Toshi Kani
2015-04-22 16:39 ` Toshi Kani
2015-04-22 17:03 ` Dan Williams
2015-04-22 17:03 ` Dan Williams
2015-04-22 18:00 ` Linda Knippers
2015-04-22 18:00 ` Linda Knippers
2015-04-22 18:20 ` Dan Williams
2015-04-22 18:20 ` Dan Williams
2015-04-22 18:23 ` Toshi Kani
2015-04-22 18:23 ` Toshi Kani
2015-04-22 19:28 ` Dan Williams
2015-04-22 19:28 ` Dan Williams
2015-04-22 19:38 ` Toshi Kani
2015-04-22 19:38 ` Toshi Kani
2015-04-22 20:00 ` Dan Williams
2015-04-22 20:00 ` Dan Williams
2015-04-28 16:47 ` Toshi Kani
2015-04-28 16:47 ` Toshi Kani
2015-04-28 17:14 ` Toshi Kani
2015-04-28 17:14 ` Toshi Kani
2015-04-18 1:35 ` [PATCH 05/21] nfit-test: manufactured NFITs for interface development Dan Williams
2015-04-18 1:35 ` Dan Williams
2015-04-24 21:47 ` [Linux-nvdimm] " Linda Knippers
2015-04-24 21:47 ` Linda Knippers
2015-04-24 21:50 ` Dan Williams
2015-04-24 21:50 ` Dan Williams
2015-04-24 21:59 ` Linda Knippers
2015-04-24 21:59 ` Linda Knippers
2015-04-24 23:02 ` Dan Williams
2015-04-24 23:02 ` Dan Williams
2015-04-28 12:54 ` Christoph Hellwig
2015-04-28 19:35 ` Dan Williams
2015-04-18 1:35 ` [PATCH 06/21] nd: ndctl class device, and nd bus attributes Dan Williams
2015-04-18 1:35 ` Dan Williams
2015-04-18 8:07 ` Greg KH
2015-04-18 8:07 ` Greg KH
2015-04-18 20:08 ` Dan Williams
2015-04-18 20:08 ` Dan Williams
2015-04-18 1:35 ` [PATCH 07/21] nd: dimm devices (nfit "memory-devices") Dan Williams
2015-04-18 1:35 ` Dan Williams
2015-04-18 8:06 ` Greg KH
2015-04-18 8:06 ` Greg KH
2015-04-18 20:12 ` Dan Williams
2015-04-18 20:12 ` Dan Williams
2015-04-18 1:35 ` [PATCH 08/21] nd: ndctl.h, the nd ioctl abi Dan Williams
2015-04-18 1:35 ` Dan Williams
2015-04-21 21:20 ` [Linux-nvdimm] " Toshi Kani
2015-04-21 21:20 ` Toshi Kani
2015-04-21 22:05 ` Dan Williams
2015-04-21 22:05 ` Dan Williams
2015-04-21 22:16 ` Toshi Kani
2015-04-21 22:16 ` Toshi Kani
2015-04-24 15:56 ` Toshi Kani
2015-04-24 15:56 ` Toshi Kani
2015-04-24 16:09 ` Toshi Kani
2015-04-24 16:09 ` Toshi Kani
2015-04-24 16:31 ` Dan Williams
2015-04-24 16:31 ` Dan Williams
2015-04-24 16:25 ` Dan Williams
2015-04-24 16:25 ` Dan Williams
2015-04-24 17:18 ` Toshi Kani
2015-04-24 17:18 ` Toshi Kani
2015-04-24 17:45 ` Dan Williams
2015-04-24 17:45 ` Dan Williams
2015-04-25 0:35 ` Toshi Kani
2015-04-25 0:35 ` Toshi Kani
2015-04-18 1:36 ` [PATCH 09/21] nd_dimm: dimm driver and base nd-bus device-driver infrastructure Dan Williams
2015-04-18 1:36 ` Dan Williams
2015-04-18 1:36 ` [PATCH 10/21] nd: regions (block-data-window, persistent memory, volatile memory) Dan Williams
2015-04-18 1:36 ` Dan Williams
2015-04-18 1:36 ` [PATCH 11/21] nd_region: support for legacy nvdimms Dan Williams
2015-04-18 1:36 ` Dan Williams
2015-04-18 1:36 ` [PATCH 12/21] nd_pmem: add NFIT support to the pmem driver Dan Williams
2015-04-18 1:36 ` Dan Williams
2015-04-18 6:38 ` Christoph Hellwig
2015-04-18 6:38 ` Christoph Hellwig
2015-04-18 19:37 ` Dan Williams
2015-04-18 19:37 ` Dan Williams
2015-04-28 12:56 ` [Linux-nvdimm] " Christoph Hellwig
2015-04-28 19:37 ` Dan Williams
2015-04-18 1:36 ` [PATCH 13/21] nd: add interleave-set state-tracking infrastructure Dan Williams
2015-04-18 1:36 ` Dan Williams
2015-04-18 1:36 ` [PATCH 14/21] nd: namespace indices: read and validate Dan Williams
2015-04-18 1:36 ` Dan Williams
2015-04-18 1:36 ` [PATCH 15/21] nd: pmem label sets and namespace instantiation Dan Williams
2015-04-18 1:36 ` Dan Williams
2015-04-18 1:36 ` [PATCH 16/21] nd: blk labels " Dan Williams
2015-04-18 1:36 ` Dan Williams
2015-04-18 1:36 ` [PATCH 17/21] nd: write pmem label set Dan Williams
2015-04-18 1:36 ` Dan Williams
2015-04-18 1:36 ` [PATCH 18/21] nd: write blk " Dan Williams
2015-04-18 1:36 ` Dan Williams
2015-04-18 1:36 ` [PATCH 19/21] nd: infrastructure for btt devices Dan Williams
2015-04-18 1:36 ` Dan Williams
2015-04-22 19:12 ` [Linux-nvdimm] " Elliott, Robert (Server Storage)
2015-04-22 19:12 ` Elliott, Robert (Server Storage)
2015-04-22 19:39 ` Dan Williams
2015-04-22 19:39 ` Dan Williams
2015-04-28 13:01 ` Christoph Hellwig
2015-04-28 15:42 ` Matthew Wilcox
2015-04-18 1:37 ` [PATCH 20/21] nd_btt: atomic sector updates Dan Williams
2015-04-18 1:37 ` Dan Williams
2015-04-18 1:37 ` [PATCH 21/21] nd_blk: nfit blk driver Dan Williams
2015-04-18 1:37 ` Dan Williams
2015-04-18 19:29 ` [PATCH 00/21] ND: NFIT-Defined / NVDIMM Subsystem Dan Williams
2015-04-18 19:29 ` Dan Williams
2015-04-22 19:06 ` [Linux-nvdimm] " Elliott, Robert (Server Storage)
2015-04-22 19:06 ` Elliott, Robert (Server Storage)
2015-04-22 19:06 ` Elliott, Robert (Server Storage)
2015-04-22 19:39 ` Dan Williams
2015-04-22 19:39 ` Dan Williams
2015-04-22 19:39 ` Dan Williams
2015-04-23 5:43 ` Ingo Molnar
2015-04-23 5:43 ` Ingo Molnar
2015-04-23 5:43 ` Ingo Molnar
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=20150420125338.GA5463@lst.de \
--to=hch@lst.de \
--cc=akpm@linux-foundation.org \
--cc=axboe@fb.com \
--cc=boaz@plexistor.com \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=neilb@suse.de \
--cc=torvalds@linux-foundation.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.