On Wed, Mar 25, 2015 at 9:44 AM, Christoph Hellwig <hch@xxxxxx> wrote: > On Wed, Mar 25, 2015 at 09:33:52AM -0700, Dan Williams wrote: >> This is mostly ok and does not collide too much with the upcoming ACPI >> mechanism for this stuff. I do worry that the new >> "memmap=nn[KMG]!ss[KMG]" kernel command line option will only be >> relevant for at most one kernel cycle given the imminent publication >> of the spec that unblocks our release. > > I don't think we can just get rid of it as legacy systems won't be > upgraded to the new discovery mechanism. Or do you mean you plan to > introduce a better override on the command line? In that case speak > up now! 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". >> Our planned solution to the "legacy pmem" problem is to have a >> userspace utility craft a list of address ranges in the form that ACPI >> expects and attach that to a platform device (one time setup). It >> only requires that the memory be marked reserved, not necessarily >> marked type-12. > > I can't see any benefit of that over just doign the right thing in > kernel space. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
