Messages in this thread |  | | Date | Mon, 20 Apr 2015 09:06:24 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 02/21] ND NFIT-Defined/NVIDIMM Subsystem |
| |
* Dan Williams <dan.j.williams@intel.com> wrote:
> Maintainer information and documenation for drivers/block/nd/ > > Cc: Andy Lutomirski <luto@amacapital.net> > Cc: Boaz Harrosh <boaz@plexistor.com> > Cc: H. Peter Anvin <hpa@zytor.com> > Cc: Jens Axboe <axboe@fb.com> > Cc: Ingo Molnar <mingo@kernel.org> > Cc: Christoph Hellwig <hch@lst.de> > Cc: Neil Brown <neilb@suse.de> > Cc: Greg KH <gregkh@linuxfoundation.org> > Signed-off-by: Dan Williams <dan.j.williams@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 000000000000..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-nvdimm@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
|  |