3:02 a.m.
On Tue, Jun 2, 2015 at 11:55 PM, Christoph Hellwig <hch(a)lst.de> 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.