Re: [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

2015-08-17 Thread Dan Williams
On Mon, Aug 17, 2015 at 8:01 AM, Christoph Hellwig wrote: > On Sat, Aug 15, 2015 at 09:04:02AM -0700, Dan Williams wrote: >> What other layer? /sys/devices/platform/e820_pmem is that exact same >> device we had before this patch. We just have a proper driver for it >> now. > > We're adding

Re: [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

2015-08-17 Thread Christoph Hellwig
On Sat, Aug 15, 2015 at 09:04:02AM -0700, Dan Williams wrote: > What other layer? /sys/devices/platform/e820_pmem is that exact same > device we had before this patch. We just have a proper driver for it > now. We're adding another layer of indirection between the old e820 file and the new

Re: [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

2015-08-17 Thread Dan Williams
On Mon, Aug 17, 2015 at 8:01 AM, Christoph Hellwig h...@lst.de wrote: On Sat, Aug 15, 2015 at 09:04:02AM -0700, Dan Williams wrote: What other layer? /sys/devices/platform/e820_pmem is that exact same device we had before this patch. We just have a proper driver for it now. We're adding

Re: [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

2015-08-17 Thread Christoph Hellwig
On Sat, Aug 15, 2015 at 09:04:02AM -0700, Dan Williams wrote: What other layer? /sys/devices/platform/e820_pmem is that exact same device we had before this patch. We just have a proper driver for it now. We're adding another layer of indirection between the old e820 file and the new module.

Re: [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

2015-08-15 Thread Dan Williams
On Sat, Aug 15, 2015 at 8:58 AM, Christoph Hellwig wrote: > On Sat, Aug 15, 2015 at 08:28:35AM -0700, Dan Williams wrote: >> I'm not grokking the argument against allowing this functionality to >> be modular. > > You're adding a another layer of platform_devices just to make a tivially > small

Re: [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

2015-08-15 Thread Christoph Hellwig
On Sat, Aug 15, 2015 at 08:28:35AM -0700, Dan Williams wrote: > I'm not grokking the argument against allowing this functionality to > be modular. You're adding a another layer of platform_devices just to make a tivially small piece of code modular so that you can hook into it. I don't think

Re: [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

2015-08-15 Thread Dan Williams
On Sat, Aug 15, 2015 at 2:06 AM, Christoph Hellwig wrote: > On Wed, Aug 12, 2015 at 11:50:29PM -0400, Dan Williams wrote: >> Purely for ease of testing, with this in place we can run the unit test >> alongside any tests that depend on the memmap=ss!nn kernel parameter. >> The unit test mocking

Re: [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

2015-08-15 Thread Christoph Hellwig
On Wed, Aug 12, 2015 at 11:50:29PM -0400, Dan Williams wrote: > Purely for ease of testing, with this in place we can run the unit test > alongside any tests that depend on the memmap=ss!nn kernel parameter. > The unit test mocking implementation requires that libnvdimm be a module > and not

Re: [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

2015-08-15 Thread Christoph Hellwig
On Wed, Aug 12, 2015 at 11:50:29PM -0400, Dan Williams wrote: Purely for ease of testing, with this in place we can run the unit test alongside any tests that depend on the memmap=ss!nn kernel parameter. The unit test mocking implementation requires that libnvdimm be a module and not built-in.

Re: [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

2015-08-15 Thread Dan Williams
On Sat, Aug 15, 2015 at 2:06 AM, Christoph Hellwig h...@lst.de wrote: On Wed, Aug 12, 2015 at 11:50:29PM -0400, Dan Williams wrote: Purely for ease of testing, with this in place we can run the unit test alongside any tests that depend on the memmap=ss!nn kernel parameter. The unit test

Re: [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

2015-08-15 Thread Dan Williams
On Sat, Aug 15, 2015 at 8:58 AM, Christoph Hellwig h...@lst.de wrote: On Sat, Aug 15, 2015 at 08:28:35AM -0700, Dan Williams wrote: I'm not grokking the argument against allowing this functionality to be modular. You're adding a another layer of platform_devices just to make a tivially small

Re: [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

2015-08-15 Thread Christoph Hellwig
On Sat, Aug 15, 2015 at 08:28:35AM -0700, Dan Williams wrote: I'm not grokking the argument against allowing this functionality to be modular. You're adding a another layer of platform_devices just to make a tivially small piece of code modular so that you can hook into it. I don't think

[RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

2015-08-12 Thread Dan Williams
Purely for ease of testing, with this in place we can run the unit test alongside any tests that depend on the memmap=ss!nn kernel parameter. The unit test mocking implementation requires that libnvdimm be a module and not built-in. A nice side effect is the implementation is a bit more generic

[RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

2015-08-12 Thread Dan Williams
Purely for ease of testing, with this in place we can run the unit test alongside any tests that depend on the memmap=ss!nn kernel parameter. The unit test mocking implementation requires that libnvdimm be a module and not built-in. A nice side effect is the implementation is a bit more generic