On Mon, Apr 13, 2015 at 2:01 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, Mar 25, 2015 at 10:00:26AM -0700, Dan Williams wrote: >> 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". > > Um, what parses that "binary table"? The kernel better not be doing > that, as that's not what the firmware interface is for. The firmware > interface is for "pass through" only directly to hardware. I had been using it as a generic/device-model-integrated way to do what amounts to ACPI table injection [1]. But, now that the new memmap= command line is upstream, most of the benefits of this approach are moot and no longer outweigh the downsides [2]. Consider it tabled. [1]: https://01.org/linux-acpi/documentation/overriding-dsdt [2]: http://marc.info/?l=linux-netdev&m=135793331325647&w=2 -- 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
