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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 3 Jun 2015 00:02:53 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Christoph Hellwig <hch@....de>
Cc:	Jens Axboe <axboe@...nel.dk>, Boaz Harrosh <boaz@...xistor.com>,
	Neil Brown <neilb@...e.de>, Dave Chinner <david@...morbit.com>,
	Lv Zheng <lv.zheng@...el.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Robert Moore <robert.moore@...el.com>,
	Ingo Molnar <mingo@...nel.org>,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	jmoyer <jmoyer@...hat.com>,
	Nicholas Moulin <nicholas.w.moulin@...ux.intel.com>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	Vishal Verma <vishal.l.verma@...ux.intel.com>,
	Jens Axboe <axboe@...com>, Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Greg KH <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [GIT PULL v4 00/21] libnd: non-volatile memory device support

On Tue, Jun 2, 2015 at 11:55 PM, Christoph Hellwig <hch@....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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/