From mboxrd@z Thu Jan  1 00:00:00 1970
From: Boaz Harrosh <boaz@plexistor.com>
Subject: Re: [Linux-nvdimm] [PATCH v2] pmem: Initial version of persistent
 memory driver
Date: Sun, 14 Sep 2014 14:18:18 +0300
Message-ID: <5415797A.7000700@plexistor.com>
References: <1409173922-7484-1-git-send-email-ross.zwisler@linux.intel.com>	<1409173922-7484-2-git-send-email-ross.zwisler@linux.intel.com>	<540F2977.7010006@plexistor.com>	<CAPcyv4gZBdtup+DuaYL2zOhP9KcRzDAq6vLih0tbpL+abGQv-g@mail.gmail.com>	<541050E5.60502@gmail.com>	<CAPcyv4hfNX4Q75AERfF4g5MVvG82j3tXWcunWiGpBgDS2+7_1Q@mail.gmail.com>	<54108ECA.6090200@plexistor.com>	<CAPcyv4gqyiTaSJY56ZrJh05kwh9O9sXNKOz40fGu5s_=eY=U6Q@mail.gmail.com>	<54117D3A.3010305@plexistor.com> <CAPcyv4io2P1TiXdnhQJMiWsYE5Rz+BiiAHqKZhDe5gh88PEWUA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Boaz Harrosh <openosd@gmail.com>,
	Ross Zwisler <ross.zwisler@linux.intel.com>,
	Jens Axboe <axboe@kernel.dk>,
	Matthew Wilcox <matthew.r.wilcox@intel.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-nvdimm@lists.01.org
To: Dan Williams <dan.j.williams@intel.com>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail-pa0-f53.google.com ([209.85.220.53]:64089 "EHLO
	mail-pa0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752439AbaINLSY (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Sun, 14 Sep 2014 07:18:24 -0400
Received: by mail-pa0-f53.google.com with SMTP id rd3so4460005pab.26
        for <linux-fsdevel@vger.kernel.org>; Sun, 14 Sep 2014 04:18:24 -0700 (PDT)
In-Reply-To: <CAPcyv4io2P1TiXdnhQJMiWsYE5Rz+BiiAHqKZhDe5gh88PEWUA@mail.gmail.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On 09/11/2014 07:31 PM, Dan Williams wrote:
<>
> 
> The point I am getting at is not requiring a priori knowledge of the
> physical memory map of a system.  Rather, place holder variables to
> enable simple dynamic discovery.
> 

"simple dynamic discovery" does not yet exist and when the DDR4 NvDIMM
will be released then we still have those DDR3 out there which will
not work with the new discovery, which I need to support as well.

And ... The submitted API will always need to exist for the emulation
case for the developer who wants to do memmap= at Kernel command line.
Which does not have any "dynamic-discovery" because it is not a real
device.

And my point was that the "dynamic-discovery" can be d-coupled from
pmem, and be driven via udev. Each technology/ARCH may have its own
"dynamic-discovery" method and drivers, yet all load a generic pmem driver.

<>
> Why start on step 2 when we haven't got agreement on step 1?
> 

So what you are saying that you do not agree with pmem driver at all?

Because my patch came to better the one range global memory parameters
of prd_start= , prd_size=, prd_nr= interface submitted by Ross to a
simple map= Interface that can take us a very long way. Does cover all
of today's usage including emulated memmap= at Kernel command line.

I have not seen any objections to Ross's pmem driver in general from
you. Only to my patch which changes the API to the better, and actually
let us support all existing and future flat technologies. Yet, yes, do
not have a "dynamic discovery". Which is out of scope for pmem right now.
(And I hope will always be)

I really do not understand what you are suggesting? Are you just saying
NACK on pmem.c. It does not do its job? how can we make it does its job
then?

Thanks
Boaz