On Wed, Mar 25, 2015 at 10:04 AM, Christoph Hellwig <h...@lst.de> wrote: > 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).
You and me both... -- 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/
