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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
