Re: [Linux-nvdimm] [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
On Fri, Apr 17, 2015 at 09:35:25PM -0400, Dan Williams wrote: > Maintainer information and documenation for drivers/block/nd/ Usuaully this would go last in the series.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-nvdimm] [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
On Fri, Apr 17, 2015 at 09:35:25PM -0400, Dan Williams wrote: Maintainer information and documenation for drivers/block/nd/ Usuaully this would go last in the series.. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
On Mon, Apr 20, 2015 at 8:57 AM, Dan Williams wrote: > On Mon, Apr 20, 2015 at 5:53 AM, Christoph Hellwig wrote: >> Once I'll go through this in more detail I'll comment more. > > Sounds good. Given that the ACPICA folks are going to define their own nfit.h with possibly different structure names, that damage should be limited to just acpi.c. Currently, changing nfit.h structure field names would impact multiple files. It's a straightforward rework to disentangle, I'll post patches soon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
On Mon, Apr 20, 2015 at 8:57 AM, Dan Williams dan.j.willi...@intel.com wrote: On Mon, Apr 20, 2015 at 5:53 AM, Christoph Hellwig h...@lst.de wrote: Once I'll go through this in more detail I'll comment more. Sounds good. Given that the ACPICA folks are going to define their own nfit.h with possibly different structure names, that damage should be limited to just acpi.c. Currently, changing nfit.h structure field names would impact multiple files. It's a straightforward rework to disentangle, I'll post patches soon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
On Mon, Apr 20, 2015 at 5:53 AM, Christoph Hellwig wrote:
> [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 naming this the pmem subsystem and trying
> to have names not too tied to one specific firmware interface.
While I understand a kernel developer's natural aversion to anything
committee defined, NFIT does seem be a superset of all the base
mechanisms needed to describe NVDIMM resources. Also, it's worth
noting that meaning of 'N' in ND is purposefully vague. The whole
point of listing it as "Nfit-Defined / NvDimm Subsystem" was to
indicate that ND is generic and could also refer generally to
"Non-volatile-Devices". What's missing, in my opinion, is an existing
NVDIMM platform that would like to leverage some of base enabling that
this sub-system provides and will never have an NFIT capability. In
the absence of alternative concerns/implementations we reached for
NFIT terminology out of convenience, but I'm all up for deprecating
"NFIT-Defined" as one of the meanings of 'ND'.
> Once I'll go through this in more detail I'll comment more.
Sounds good.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
[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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
On Mon, Apr 20, 2015 at 12:06 AM, Ingo Molnar wrote:
>
> * Dan Williams wrote:
>
>> Maintainer information and documenation for drivers/block/nd/
>>
>> Cc: Andy Lutomirski
>> Cc: Boaz Harrosh
>> Cc: H. Peter Anvin
>> Cc: Jens Axboe
>> Cc: Ingo Molnar
>> Cc: Christoph Hellwig
>> Cc: Neil Brown
>> Cc: Greg KH
>> Signed-off-by: Dan Williams
>> ---
>> Documentation/blockdev/nd.txt | 867
>> +
>> MAINTAINERS | 34 +-
>> 2 files changed, 895 insertions(+), 6 deletions(-)
>> create mode 100644 Documentation/blockdev/nd.txt
>>
>> diff --git a/Documentation/blockdev/nd.txt b/Documentation/blockdev/nd.txt
>> new file mode 100644
>> index ..bcfdf21063ab
>> --- /dev/null
>> +++ b/Documentation/blockdev/nd.txt
>> @@ -0,0 +1,867 @@
>> + The NFIT-Defined/NVDIMM Sub-system (ND)
>> +
>> + nd - kernel abi / device-model & ndctl - userspace helper library
>> + linux-nvd...@lists.01.org
>> +v9: April 17th, 2015
>> +
>> +
>> + Glossary
>> +
>> + Overview
>> +Supporting Documents
>> +Git Trees
>> +
>> + NFIT Terminology and NVDIMM Types
>>
>> [...]
>>
>> +The “NVDIMM Firmware Interface Table” (NFIT) [...]
>
> Ok, I'll bite.
>
> 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.
> Why do you restrict this driver to a naming and design that is so
> firmware centric?
PMEM, BLK, and the fact that they may alias are the generic properties
that are independent of the specification. Granted some of the NFIT
terminology has leaked past the point of initial table parsing, but
its too early to start claiming "restrictive" design. We already
support three ways of attaching PMEM with varying degrees of backing
complexity, and we're more than willing to beat NFIT back where it
makes sense to accommodate more non-NFIT NVDIMM implementations.
> Discovery matters, but what matters _most_ to devices is actually its
> runtime properties and runtime implementation - and I sure hope
> firmware has no active role in that!
It doesn't. Once PMEM and BLK aliasing are resolved the firmware is
out of the picture. In some cases this aliasing is resolved from the
outset (simple memory range, type-12 etc...), the bulk of the
implementation is bypassed in that case.
> I really think this is backwards from the get go, it gives me a
> feeling of someone having spent way too much time in committee and too
> little time spent thinking about simple, proper kernel design and
> reusing existing terminology ...
The simple paths are there, in addition to support for the rest of the
spec. Do we have an existing term for a dimm-relative-address in the
kernel? Some of this is simply novel to the kernel.
> Also:
>
> + nd - kernel abi / device-model & ndctl - userspace helper library
>
> WTF is a 'kernel ABI'??
"ABI" like Documentation/ABI/, the sysfs layout and ioctls for passing
a handful of management commands to firmware. Wherever possible all
the slow path configuration is done with sysfs.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
* Dan Williams wrote:
> Maintainer information and documenation for drivers/block/nd/
>
> Cc: Andy Lutomirski
> Cc: Boaz Harrosh
> Cc: H. Peter Anvin
> Cc: Jens Axboe
> Cc: Ingo Molnar
> Cc: Christoph Hellwig
> Cc: Neil Brown
> Cc: Greg KH
> Signed-off-by: Dan Williams
> ---
> Documentation/blockdev/nd.txt | 867
> +
> MAINTAINERS | 34 +-
> 2 files changed, 895 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/blockdev/nd.txt
>
> diff --git a/Documentation/blockdev/nd.txt b/Documentation/blockdev/nd.txt
> new file mode 100644
> index ..bcfdf21063ab
> --- /dev/null
> +++ b/Documentation/blockdev/nd.txt
> @@ -0,0 +1,867 @@
> + The NFIT-Defined/NVDIMM Sub-system (ND)
> +
> + nd - kernel abi / device-model & ndctl - userspace helper library
> + linux-nvd...@lists.01.org
> +v9: April 17th, 2015
> +
> +
> + Glossary
> +
> + Overview
> +Supporting Documents
> +Git Trees
> +
> + NFIT Terminology and NVDIMM Types
>
> [...]
>
> +The “NVDIMM Firmware Interface Table” (NFIT) [...]
Ok, I'll bite.
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??
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.
Why do you restrict this driver to a naming and design that is so
firmware centric?
Discovery matters, but what matters _most_ to devices is actually its
runtime properties and runtime implementation - and I sure hope
firmware has no active role in that!
I really think this is backwards from the get go, it gives me a
feeling of someone having spent way too much time in committee and too
little time spent thinking about simple, proper kernel design and
reusing existing terminology ...
Also:
+ nd - kernel abi / device-model & ndctl - userspace helper library
WTF is a 'kernel ABI'??
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
[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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
* Dan Williams dan.j.willi...@intel.com wrote:
Maintainer information and documenation for drivers/block/nd/
Cc: Andy Lutomirski l...@amacapital.net
Cc: Boaz Harrosh b...@plexistor.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Jens Axboe ax...@fb.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Christoph Hellwig h...@lst.de
Cc: Neil Brown ne...@suse.de
Cc: Greg KH gre...@linuxfoundation.org
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
Documentation/blockdev/nd.txt | 867
+
MAINTAINERS | 34 +-
2 files changed, 895 insertions(+), 6 deletions(-)
create mode 100644 Documentation/blockdev/nd.txt
diff --git a/Documentation/blockdev/nd.txt b/Documentation/blockdev/nd.txt
new file mode 100644
index ..bcfdf21063ab
--- /dev/null
+++ b/Documentation/blockdev/nd.txt
@@ -0,0 +1,867 @@
+ The NFIT-Defined/NVDIMM Sub-system (ND)
+
+ nd - kernel abi / device-model ndctl - userspace helper library
+ linux-nvd...@lists.01.org
+v9: April 17th, 2015
+
+
+ Glossary
+
+ Overview
+Supporting Documents
+Git Trees
+
+ NFIT Terminology and NVDIMM Types
[...]
+The “NVDIMM Firmware Interface Table” (NFIT) [...]
Ok, I'll bite.
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??
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.
Why do you restrict this driver to a naming and design that is so
firmware centric?
Discovery matters, but what matters _most_ to devices is actually its
runtime properties and runtime implementation - and I sure hope
firmware has no active role in that!
I really think this is backwards from the get go, it gives me a
feeling of someone having spent way too much time in committee and too
little time spent thinking about simple, proper kernel design and
reusing existing terminology ...
Also:
+ nd - kernel abi / device-model ndctl - userspace helper library
WTF is a 'kernel ABI'??
Thanks,
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
On Mon, Apr 20, 2015 at 12:06 AM, Ingo Molnar mi...@kernel.org wrote:
* Dan Williams dan.j.willi...@intel.com wrote:
Maintainer information and documenation for drivers/block/nd/
Cc: Andy Lutomirski l...@amacapital.net
Cc: Boaz Harrosh b...@plexistor.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Jens Axboe ax...@fb.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Christoph Hellwig h...@lst.de
Cc: Neil Brown ne...@suse.de
Cc: Greg KH gre...@linuxfoundation.org
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
Documentation/blockdev/nd.txt | 867
+
MAINTAINERS | 34 +-
2 files changed, 895 insertions(+), 6 deletions(-)
create mode 100644 Documentation/blockdev/nd.txt
diff --git a/Documentation/blockdev/nd.txt b/Documentation/blockdev/nd.txt
new file mode 100644
index ..bcfdf21063ab
--- /dev/null
+++ b/Documentation/blockdev/nd.txt
@@ -0,0 +1,867 @@
+ The NFIT-Defined/NVDIMM Sub-system (ND)
+
+ nd - kernel abi / device-model ndctl - userspace helper library
+ linux-nvd...@lists.01.org
+v9: April 17th, 2015
+
+
+ Glossary
+
+ Overview
+Supporting Documents
+Git Trees
+
+ NFIT Terminology and NVDIMM Types
[...]
+The “NVDIMM Firmware Interface Table” (NFIT) [...]
Ok, I'll bite.
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.
Why do you restrict this driver to a naming and design that is so
firmware centric?
PMEM, BLK, and the fact that they may alias are the generic properties
that are independent of the specification. Granted some of the NFIT
terminology has leaked past the point of initial table parsing, but
its too early to start claiming restrictive design. We already
support three ways of attaching PMEM with varying degrees of backing
complexity, and we're more than willing to beat NFIT back where it
makes sense to accommodate more non-NFIT NVDIMM implementations.
Discovery matters, but what matters _most_ to devices is actually its
runtime properties and runtime implementation - and I sure hope
firmware has no active role in that!
It doesn't. Once PMEM and BLK aliasing are resolved the firmware is
out of the picture. In some cases this aliasing is resolved from the
outset (simple memory range, type-12 etc...), the bulk of the
implementation is bypassed in that case.
I really think this is backwards from the get go, it gives me a
feeling of someone having spent way too much time in committee and too
little time spent thinking about simple, proper kernel design and
reusing existing terminology ...
The simple paths are there, in addition to support for the rest of the
spec. Do we have an existing term for a dimm-relative-address in the
kernel? Some of this is simply novel to the kernel.
Also:
+ nd - kernel abi / device-model ndctl - userspace helper library
WTF is a 'kernel ABI'??
ABI like Documentation/ABI/, the sysfs layout and ioctls for passing
a handful of management commands to firmware. Wherever possible all
the slow path configuration is done with sysfs.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
On Mon, Apr 20, 2015 at 5:53 AM, Christoph Hellwig h...@lst.de wrote:
[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 naming this the pmem subsystem and trying
to have names not too tied to one specific firmware interface.
While I understand a kernel developer's natural aversion to anything
committee defined, NFIT does seem be a superset of all the base
mechanisms needed to describe NVDIMM resources. Also, it's worth
noting that meaning of 'N' in ND is purposefully vague. The whole
point of listing it as Nfit-Defined / NvDimm Subsystem was to
indicate that ND is generic and could also refer generally to
Non-volatile-Devices. What's missing, in my opinion, is an existing
NVDIMM platform that would like to leverage some of base enabling that
this sub-system provides and will never have an NFIT capability. In
the absence of alternative concerns/implementations we reached for
NFIT terminology out of convenience, but I'm all up for deprecating
NFIT-Defined as one of the meanings of 'ND'.
Once I'll go through this in more detail I'll comment more.
Sounds good.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
Maintainer information and documenation for drivers/block/nd/ Cc: Andy Lutomirski Cc: Boaz Harrosh Cc: H. Peter Anvin Cc: Jens Axboe Cc: Ingo Molnar Cc: Christoph Hellwig Cc: Neil Brown Cc: Greg KH Signed-off-by: Dan Williams --- Documentation/blockdev/nd.txt | 867 + MAINTAINERS | 34 +- 2 files changed, 895 insertions(+), 6 deletions(-) create mode 100644 Documentation/blockdev/nd.txt diff --git a/Documentation/blockdev/nd.txt b/Documentation/blockdev/nd.txt new file mode 100644 index ..bcfdf21063ab --- /dev/null +++ b/Documentation/blockdev/nd.txt @@ -0,0 +1,867 @@ + The NFIT-Defined/NVDIMM Sub-system (ND) + + nd - kernel abi / device-model & ndctl - userspace helper library + linux-nvd...@lists.01.org +v9: April 17th, 2015 + + + Glossary + + Overview +Supporting Documents +Git Trees + + NFIT Terminology and NVDIMM Types + + Why BLK? +PMEM vs BLK (SPA vs BDW) + BLK-REGIONs, PMEM-REGIONs, Atomic Sectors, and DAX + + Example NFIT Diagram + + ND Device Model/ABI and NDCTL API +NDCTL: Context + ndctl: instantiate a new library context example + +ND/NDCTL: Bus + nd: control class device in /sys/class + nd: bus layout + ndctl: bus enumeration example + +ND/NDCTL: DIMM (NMEM) + nd: DIMM (NMEM) layout + ndctl: DIMM enumeration example + +ND/NDCTL: Region + nd: region layout + ndctl: region enumeration example + Why Not Encode the Region Type into the Region Name? + How Do I Determine the Major Type of a Region? + +ND/NDCTL: Namespace + nd: namespace layout + ndctl: namespace enumeration example + ndctl: namespace creation example + Why the Term “namespace”? + +ND/NDCTL: Block Translation Table “btt” + nd: btt layout + ndctl: btt creation example + + Summary NDCTL Diagram + + +Glossary + + +NFIT: NVDIMM Firmware Interface Table + +SPA: System Physical Address also refers to an NFIT system-physical +address table entry describing contiguous persistent memory range. + +DPA: DIMM Physical Address, is a DIMM-relative offset. With one DIMM in +the system there would be a 1:1 SPA:DPA association. Once more DIMMs +are added an interleave-description-table provided by NFIT is needed to +decode a SPA to a DPA. + +DCR: DIMM Control Region Descriptor, an NFIT sub-table entry conveying +the vendor, format, revision, and geometry of the related +block-data-windows. + +BDW: Block Data Window Region Descriptor, an NFIT sub-table referenced +by a DCR locating a set of data transfer apertures and control registers +in system memory. + +PMEM: A linux block device which provides access to an SPA range. A PMEM +device is capable of DAX (see below). + +DAX: File system extensions to bypass the page cache and block layer to +map persistent memory, from a PMEM block device, directly into a process +address space. + +BLK: A linux block device which accesses NVDIMM storage through a BDW +(block-data-window aperture). A BLK device is not amenable to DAX. + +DSM: Device Specific Method, refers to a runtime service provided by +platform firmware to send formatted control/configuration messages to a +DIMM device. In ACPI this is an _DSM attribute of an object. + +BTT: Block Translation Table: Persistent memory is byte addressable. +Existing software may have an expectation that the power-fail-atomicity +of writes is at least one sector, 512 bytes. The BTT is an indirection +table with atomic update semantics to front a PMEM/BLK block device +driver and present arbitrary atomic sector sizes. + +LABEL: Metadata stored on a DIMM device that partitions and identifies +(persistently names) storage between PMEM and BLK. It also partitions +BLK storage to host BTTs with different parameters per BLK-partition. +Note that traditional partition tables, GPT/MBR, are layered on top of a +BLK or PMEM device. + + + + +Overview + + +The “NVDIMM Firmware Interface Table” (NFIT) defines a set of tables +that describe the non-volatile memory resources in a platform. Platform +firmware provides this table as well as runtime-services for sending +control and configuration messages to capable NVDIMM devices. NFIT is a +new top-level table in ACPI 6. The Linux ND subsystem is designed as a +generic mechanism that can register a binary NFIT from any provider, +ACPI being just one example of a provider. The unit test infrastructure +in the kernel exploits this capability to provide multiple sample NFITs +via custom test-platform-devices. + + +Supporting Documents +ACPI 6: http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf +NVDIMM Namespace: http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf +DSM Interface Example: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf +Driver Writer’s Guide:
[PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem
Maintainer information and documenation for drivers/block/nd/ Cc: Andy Lutomirski l...@amacapital.net Cc: Boaz Harrosh b...@plexistor.com Cc: H. Peter Anvin h...@zytor.com Cc: Jens Axboe ax...@fb.com Cc: Ingo Molnar mi...@kernel.org Cc: Christoph Hellwig h...@lst.de Cc: Neil Brown ne...@suse.de Cc: Greg KH gre...@linuxfoundation.org Signed-off-by: Dan Williams dan.j.willi...@intel.com --- Documentation/blockdev/nd.txt | 867 + MAINTAINERS | 34 +- 2 files changed, 895 insertions(+), 6 deletions(-) create mode 100644 Documentation/blockdev/nd.txt diff --git a/Documentation/blockdev/nd.txt b/Documentation/blockdev/nd.txt new file mode 100644 index ..bcfdf21063ab --- /dev/null +++ b/Documentation/blockdev/nd.txt @@ -0,0 +1,867 @@ + The NFIT-Defined/NVDIMM Sub-system (ND) + + nd - kernel abi / device-model ndctl - userspace helper library + linux-nvd...@lists.01.org +v9: April 17th, 2015 + + + Glossary + + Overview +Supporting Documents +Git Trees + + NFIT Terminology and NVDIMM Types + + Why BLK? +PMEM vs BLK (SPA vs BDW) + BLK-REGIONs, PMEM-REGIONs, Atomic Sectors, and DAX + + Example NFIT Diagram + + ND Device Model/ABI and NDCTL API +NDCTL: Context + ndctl: instantiate a new library context example + +ND/NDCTL: Bus + nd: control class device in /sys/class + nd: bus layout + ndctl: bus enumeration example + +ND/NDCTL: DIMM (NMEM) + nd: DIMM (NMEM) layout + ndctl: DIMM enumeration example + +ND/NDCTL: Region + nd: region layout + ndctl: region enumeration example + Why Not Encode the Region Type into the Region Name? + How Do I Determine the Major Type of a Region? + +ND/NDCTL: Namespace + nd: namespace layout + ndctl: namespace enumeration example + ndctl: namespace creation example + Why the Term “namespace”? + +ND/NDCTL: Block Translation Table “btt” + nd: btt layout + ndctl: btt creation example + + Summary NDCTL Diagram + + +Glossary + + +NFIT: NVDIMM Firmware Interface Table + +SPA: System Physical Address also refers to an NFIT system-physical +address table entry describing contiguous persistent memory range. + +DPA: DIMM Physical Address, is a DIMM-relative offset. With one DIMM in +the system there would be a 1:1 SPA:DPA association. Once more DIMMs +are added an interleave-description-table provided by NFIT is needed to +decode a SPA to a DPA. + +DCR: DIMM Control Region Descriptor, an NFIT sub-table entry conveying +the vendor, format, revision, and geometry of the related +block-data-windows. + +BDW: Block Data Window Region Descriptor, an NFIT sub-table referenced +by a DCR locating a set of data transfer apertures and control registers +in system memory. + +PMEM: A linux block device which provides access to an SPA range. A PMEM +device is capable of DAX (see below). + +DAX: File system extensions to bypass the page cache and block layer to +map persistent memory, from a PMEM block device, directly into a process +address space. + +BLK: A linux block device which accesses NVDIMM storage through a BDW +(block-data-window aperture). A BLK device is not amenable to DAX. + +DSM: Device Specific Method, refers to a runtime service provided by +platform firmware to send formatted control/configuration messages to a +DIMM device. In ACPI this is an _DSM attribute of an object. + +BTT: Block Translation Table: Persistent memory is byte addressable. +Existing software may have an expectation that the power-fail-atomicity +of writes is at least one sector, 512 bytes. The BTT is an indirection +table with atomic update semantics to front a PMEM/BLK block device +driver and present arbitrary atomic sector sizes. + +LABEL: Metadata stored on a DIMM device that partitions and identifies +(persistently names) storage between PMEM and BLK. It also partitions +BLK storage to host BTTs with different parameters per BLK-partition. +Note that traditional partition tables, GPT/MBR, are layered on top of a +BLK or PMEM device. + + + + +Overview + + +The “NVDIMM Firmware Interface Table” (NFIT) defines a set of tables +that describe the non-volatile memory resources in a platform. Platform +firmware provides this table as well as runtime-services for sending +control and configuration messages to capable NVDIMM devices. NFIT is a +new top-level table in ACPI 6. The Linux ND subsystem is designed as a +generic mechanism that can register a binary NFIT from any provider, +ACPI being just one example of a provider. The unit test infrastructure +in the kernel exploits this capability to provide multiple sample NFITs +via custom test-platform-devices. + + +Supporting Documents +ACPI 6: http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf +NVDIMM Namespace: http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf
