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). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
