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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150603065510.GB11344@lst.de>
Date:	Wed, 3 Jun 2015 08:55:10 +0200
From:	Christoph Hellwig <hch@....de>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	Christoph Hellwig <hch@....de>, 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 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.

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.

> 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.
--
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/