Re: [RFC PATCH] libnvdimm: Update the meaning for persistence_domain values

["Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>]

On 1/15/20 11:05 PM, Jeff Moyer wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> 

>>>> diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
>>>> index f2a33f2e3ba8..9126737377e1 100644
>>>> --- a/include/linux/libnvdimm.h
>>>> +++ b/include/linux/libnvdimm.h
>>>> @@ -52,9 +52,9 @@ enum {
>>>>    	 */
>>>>    	ND_REGION_PERSIST_CACHE = 1,
>>>>    	/*
>>>> -	 * Platform provides mechanisms to automatically flush outstanding
>>>> -	 * write data from memory controler to pmem on system power loss.
>>>> -	 * (ADR)
>>>> +	 * Platform provides instructions to flush data such that on completion
>>>> +	 * of the instructions, data flushed is guaranteed to be on pmem even
>>>> +	 * in case of a system power loss.
>>>
>>> I find the prior description easier to understand.
>>
>> I was trying to avoid the term 'automatically, 'memory controler' and
>> ADR. Can I update the above as
> 
> I can understand avoiding the very x86-specific "ADR," but is memory
> controller not accurate for your platform?
> 
>> /*
>>   * Platform provides mechanisms to flush outstanding write data
>>   * to pmem on system power loss.
>>   */
> 
> That's way too broad.  :) The comments are describing the persistence
> domain.  i.e. if you get data to $HERE, it is guaranteed to make it out
> to stable media.

With technologies like OpenCAPI, we possibly may not want to call them 
"memory controller"? In a way platform mechanism will flush them such 
that on power failure, it is guaranteed to be on the pmem media. But 
should we call these boundary "memory_controller"? May be we can 
consider "memory controller" an overloaded term there. Considering we 
are  calling this as memory_controller for application to parse via 
sysfs, may be the documentation can also carry the same term.

-aneesh
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org