From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [Linux-nvdimm] another pmem variant Date: Wed, 25 Mar 2015 18:04:30 +0100 Message-ID: <20150325170430.GA2223@lst.de> References: <1427299449-26722-1-git-send-email-hch@lst.de> <20150325164428.GA1099@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , linux-nvdimm , linux-fsdevel , "linux-kernel@vger.kernel.org" , X86 ML , Jens Axboe To: Dan Williams Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote: > The kernel command line would simply be the standard/existing memmap= > to reserve a memory range. Then, when the platform device loads, it > does a request_firmware() to inject a binary table that further carves > memory into ranges to which the pmem driver attaches. No need for the > legacy system BIOS to be upgraded to the "new way". Ewww... > It does do the right thing in kernel space. The userspace utility > creates the binary table (once) that can be compiled into the platform > device driver or auto-loaded by an initrd. The problem with a new > memmap= is that it is too coarse. For example you can't do things > like specify a pmem range per-NUMA node. Sure you can as long as you know the layout. memmap= can be specified multiple times. Again, I see absolutely zero benefit of doing crap like request_firmware() to convert interface, and I'm also tired of having this talk about code that will eventually be released and should be superior (and from all that I can guess so far will actually be far worse).