Messages in this thread | | | Date | Wed, 25 Mar 2015 18:04:30 +0100 | From | Christoph Hellwig <> | Subject | Re: [Linux-nvdimm] another pmem variant |
| |
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).
| |