lizhijian@xxxxxxxxxxx wrote: [..] > Case D: unsupported && need your input To support this situation, the > makedumpfile needs to know the location of metadata for each pmem > namespace and the address and size of metadata in the pmem [start, > end) My first reaction is that you should copy what the ndctl utility does when it needs to manipulate or interrogate the metadata space. For example, see namespace_rw_infoblock(): https://github.com/pmem/ndctl/blob/main/ndctl/namespace.c#L2022 That facility uses the force_raw attribute ("/sys/bus/nd/devices/namespaceX.Y/force_raw") to arrange for the namespace to initalize without considering any pre-existing metdata *and* without overwriting it. In that mode makedumpfile can walk the namespaces and retrieve the metadata written by the previous kernel. The module to block to allow makedumpfile to access the namespace in raw mode is the nd_pmem module, or if it is builtin the nd_pmem_driver_init() initcall.
