From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754011AbbCYREe (ORCPT <rfc822;w@1wt.eu>);
	Wed, 25 Mar 2015 13:04:34 -0400
Received: from verein.lst.de ([213.95.11.211]:48778 "EHLO newverein.lst.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752611AbbCYREc (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 25 Mar 2015 13:04:32 -0400
Date: Wed, 25 Mar 2015 18:04:30 +0100
From: Christoph Hellwig <hch@lst.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Christoph Hellwig <hch@lst.de>, linux-nvdimm <linux-nvdimm@ml01.01.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        X86 ML <x86@kernel.org>, Jens Axboe <axboe@kernel.dk>
Subject: Re: [Linux-nvdimm] another pmem variant
Message-ID: <20150325170430.GA2223@lst.de>
References: <1427299449-26722-1-git-send-email-hch@lst.de> <CAPcyv4gaGQ-4bYp2djHnLGLLCr9gD8pZP2Lb1ACNP8G4fSzd=w@mail.gmail.com> <20150325164428.GA1099@lst.de> <CAPcyv4jYMziV3F5FE8S5jT6c_xtMJ0R45x3huKJ_JKOi2WPy4w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPcyv4jYMziV3F5FE8S5jT6c_xtMJ0R45x3huKJ_JKOi2WPy4w@mail.gmail.com>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@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).