linux-kernel - Re: [PATCH 1/3] pmem: Initial version of persistent memory driver

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

Message-Id: <201504081833.t38IXN4q003069@wind.enjellic.com>
Date:	Wed, 8 Apr 2015 13:33:23 -0500
From:	"Dr. Greg Wettstein" <greg@...d.enjellic.com>
To:	Christoph Hellwig <hch@....de>, linux-nvdimm@...1.01.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	x86@...nel.org
Cc:	ross.zwisler@...ux.intel.com, axboe@...nel.dk, boaz@...xistor.com
Subject: Re: [PATCH 1/3] pmem: Initial version of persistent memory driver

On Mar 26,  9:32am, Christoph Hellwig wrote:
} Subject: [PATCH 1/3] pmem: Initial version of persistent memory driver

Hi, I hope the week has been going well for everyone.

> From: Ross Zwisler <ross.zwisler@...ux.intel.com>
> 
> PMEM is a new driver that presents a reserved range of memory as a
> block device.  This is useful for developing with NV-DIMMs, and
> can be used with volatile memory as a development platform.

We are interested in NV-DIMM's for a variety of reasons so the
discussion on this has been interesting, particularly the 'correct'
method of abstracting access.

We needed a block device representation of memory for a number of
projects we are working on and put the following together:

ftp://ftp.enjellic.com/pub/hpd/hpd_driver-1.1beta.tar.gz

Which has patches for 3.10 and 3.14.

We built HPD on top of the hugepage kernel infrastructure.  In our
opinion, for whatever that is worth, there were a number of advantages
to building this on a page based abstraction.  Not the least of which
was that NUMA awareness just naturally fell out of that model.

While the above patches don't have support for 1GB pages in them that
was also a straight forward exercise.

I don't even pretend to understand all the complexities and mechanics
of the E820/EFI memory mapping issues involved or the various issues
with persistency triggers and such but mapping these through something
like the hugepage infrastructure 'feels' like it would have a number
of longterm advantages with respect to isolating implementations from
the block layer interface.

Have a good remainder of the week.

Greg

}-- End of excerpt from Christoph Hellwig

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@...ellic.com
------------------------------------------------------------------------------
"This patch causes a CONFIG_PREEMPT=y, CONFIG_PREEMPT_BKL=y,
 CONFIG_DEBUG_PREEMPT=y kernel on a ppc64 G5 to hang immediately after
 displaying the penguins, but apparently not before having set the
 hardware clock backwards 101 years."

"After having carefully reviewed the above description and having
 decided that these effects were not a part of the patch's design
 intent I have temporarily set it aside, thanks."
                                -- Andrew Morton
                                   linux-kernel
--
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/