From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752353AbbCZRTC (ORCPT ); Thu, 26 Mar 2015 13:19:02 -0400 Received: from verein.lst.de ([213.95.11.211]:53316 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750819AbbCZRTA (ORCPT ); Thu, 26 Mar 2015 13:19:00 -0400 Date: Thu, 26 Mar 2015 18:18:58 +0100 From: Christoph Hellwig To: Boaz Harrosh Cc: linux-nvdimm@ml01.01.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, ross.zwisler@linux.intel.com, axboe@kernel.dk Subject: Re: another pmem variant V2 Message-ID: <20150326171858.GA25575@lst.de> References: <1427358764-6126-1-git-send-email-hch@lst.de> <55143A8B.2060304@plexistor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55143A8B.2060304@plexistor.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 26, 2015 at 06:57:47PM +0200, Boaz Harrosh wrote: > For one this auto discovery of yours is very (very) nice but is a bit > inconvenience. Before I would reserve a big chuck on each NUMA range > on Kernel's memmap= And then at pmem map= would slice and dice it > as I want hot style on modprobe with no need for reboot. Now I need > to do it on reboot theoretically. (You know xfstest needs lots of devices > some big some small ;-)) Slicing up a block device based on kernel options is not exactly a smart idea. We have partitions that are perfectly fine for that. If you really don't are about persistance of your partitioning you can just set up a device mapper table. No need to reinvent the wheel. > Also with the modprob pmem map= I was supporting a PCIE memory card but > I guess I need to throw this one out the door. Send it my way to support it properly... Just like any other PCIe device it should have a proper driver. For now it can register a pmem platform device, but when you submit it I'd rather add slightly more low-level versions of pmem_probe and pmem_remove that take a struct device * and possibly a resource structure so that you can directly call into it.