Re: [GIT PULL v4 00/21] libnd: non-volatile memory device support

From: Dan Williams
Date: Wed Jun 03 2015 - 03:03:11 EST


On Tue, Jun 2, 2015 at 11:55 PM, Christoph Hellwig <hch@xxxxxx> wrote:
> On Thu, May 28, 2015 at 07:55:47AM -0700, Dan Williams wrote:
>> > - stong NAK for the linker wrapping abuse in the test module
>>
>> This capability has been our single largest generator of bug fixes and
>> regression prevention. Please tell me you have a non-bikeshed
>> argument why this test approach must die? We need more tests in tree,
>> not less. That said, it's at the end of the series ready to be lopped
>> off like a spent booster rocket if it's really a blocker.
>
> No - you're overloading general functionality to go to something much
> slower, with locking implications etc totally invisible to someone reading
> the code. I could be persuaded that a test module makes sense if you
> make it an explicit opt-in at the source code level, e.g. a version
> of a the pmem driver that needs to be explicitly loaded.

I slowly came to the same realization, see v5.

> Then again I really don't see the point - if you already need a VM with
> ACPI / EFI tables to claim that you have pmem support you might as well
> do the pmem emulation in that same virtualÑzation environment.

The problem is that PMEM is easy to emulate, BLK, is more involved.
No one really wants BLK mode in a VM compared to a virtio passthrough
to BLK mode on the bare metal side.

>> It makes the identifier prefixes shorter is the bulk of the reasoning
>> and a hardware memory resource need not always be a "dimm". If it's
>> just the top-level directory I'm fine with 'nvdimm' or are you looking
>> for a rename throughout?
>
> That's the most important part.

Ok, have a look at v5 and see if that seems like the right set of
identifier names.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/