[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150326171858.GA25575@lst.de>
Date: Thu, 26 Mar 2015 18:18:58 +0100
From: Christoph Hellwig <hch@....de>
To: Boaz Harrosh <boaz@...xistor.com>
Cc: linux-nvdimm@...1.01.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, x86@...nel.org,
ross.zwisler@...ux.intel.com, axboe@...nel.dk
Subject: Re: another pmem variant V2
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.
--
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/
Powered by blists - more mailing lists