On 09/11/2014 07:31 PM, Dan Williams wrote: <> > > The point I am getting at is not requiring a priori knowledge of the > physical memory map of a system. Rather, place holder variables to > enable simple dynamic discovery. > "simple dynamic discovery" does not yet exist and when the DDR4 NvDIMM will be released then we still have those DDR3 out there which will not work with the new discovery, which I need to support as well. And ... The submitted API will always need to exist for the emulation case for the developer who wants to do memmap= at Kernel command line. Which does not have any "dynamic-discovery" because it is not a real device. And my point was that the "dynamic-discovery" can be d-coupled from pmem, and be driven via udev. Each technology/ARCH may have its own "dynamic-discovery" method and drivers, yet all load a generic pmem driver. <> > Why start on step 2 when we haven't got agreement on step 1? > So what you are saying that you do not agree with pmem driver at all? Because my patch came to better the one range global memory parameters of prd_start= , prd_size=, prd_nr= interface submitted by Ross to a simple map= Interface that can take us a very long way. Does cover all of today's usage including emulated memmap= at Kernel command line. I have not seen any objections to Ross's pmem driver in general from you. Only to my patch which changes the API to the better, and actually let us support all existing and future flat technologies. Yet, yes, do not have a "dynamic discovery". Which is out of scope for pmem right now. (And I hope will always be) I really do not understand what you are suggesting? Are you just saying NACK on pmem.c. It does not do its job? how can we make it does its job then? Thanks Boaz -- 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
