On 02/11/2015 05:48 PM, Jiang, Dave wrote:
While there are no issues getting you the source of ADRBD, it's
probably counterproductive. It's a bit of history. There is no
official memory type in the APCI spec for NVDIMM yet. Originally we
set it for type 6 as an experiment but then type 6 was taken. Then we
basically said screw it and set it for type 12 until something
official happens. The ADRBD code basically puts in a hack during the
memory initialization code to claim all type 12 memory as special
reserved type and exports a platform device with the resources. When
the driver probes, it picks up the platform device and exposes the
memory ranges as block devices. Going forward we want to move towards
pmem and away from adrbd as the hacks are not upstreamable (therefore
not distributed to the wider public). And there really isn't any
reason we can't use pmem as the common code base. ADRBD was always
provided as reference code more than anything else. The bottom line
is pmem is where we are going and we should focus on improving that
and get that to work for all NVDIMM types.
Hi Sir Dave
Not sure if you have noticed, I kind of father pmem and am actively
maintaining my own advanced version of this driver.
We have our own changes to e820.c to support type 12. I intend
to eventually push this change to Kernel.
Because APCI spec, or not, There are out there, (And here in our lab)
type 12 DDR3 NvDIMMs and that is an hard cold fact. ACPI comity better
black list this type, yes I dare them to define a type-12 for something
else. I understand this is considered bad politics, but life is stronger
than any comity or politics and these chips are out there because users
wants them and already use them, and type 12 is good as any.
We just used "reserved" for type 12 right now, but I want to define
a "DDR3 NvDIMM" new type and constant (12). (I'd love if DDR4 would
use the de-fecto STD type 12 as well and I'll change the name to
With this very small definition to e820.c, and the current pmem.c
driver. We are able to auto load any and multiple NvDIMMs with an
help of an autoload_pmem script. (actually autoload_pmem also
works without the changes to e820.c)
Yes please send me the ADRBD source code I want it as a reference
code that has some experience in the field with some of the vendors.
All I can test with is the two vendors I have, so it will give me
more confidence that I have not missed some details with current chips.
From what I understand they all use type-12 and this comes up as
in the call to request_mem_region_exclusive(), with current code.
All I'm changing is to make it start as "available" at startup.
Even with no changes to e820.c I can just ignore the failure of
request_mem_region_exclusive() and continue to use the chips. As is.
I promise to not publish the driver or anything like that. I only
need it as reference code.
Thanks in advance