On Mon, Nov 6, 2017 at 6:50 PM, Elliott, Robert (Persistent Memory) <elli...@hpe.com> wrote: > > >> -----Original Message----- >> From: Linux-nvdimm [mailto:linux-nvdimm-boun...@lists.01.org] On >> Behalf Of Dan Williams >> Sent: Monday, November 06, 2017 5:32 PM >> To: Lijun Pan <lijun....@dell.com> >> Cc: linux-nvdimm@lists.01.org >> Subject: Re: [PATCH] acpi/nfit: export read_only attribute of dimms >> >> On Mon, Oct 30, 2017 at 1:41 PM, Lijun Pan <lijun....@dell.com> >> wrote: >> > Though flags attribute provides enough information about >> > the dimm, it is nice to export the read_only attribute if >> > bit3 of NVDIMM state flag is set. >> > If error is injected by BIOS, bit3 and bit1 are both set. >> > If DIMM is set to read-only by BIOS, bit3 is set. >> > Hence bit3 is good enough to tell whether the dimm is in >> > read-only mode or not. >> >> Hmm, can you say about more about why we need this additional >> attribute? >> >> Applications don't read and write the DIMM directly, they only >> interface with the DIMM through namespaces of a given region. The >> region device already has a 'read_only' attribute. See >> read_only_show() in drivers/nvdimm/region_devs.c. > > A few more points: > > 1. The full NVDIMM State Flags value is already reported for > the nmem device, so reporting bit 3 separately as "read_only" > would be redundant. > > 2. For NVDIMM-Ns, the system is not preventing writing to memory; > system firmware is just warning that any writes will not be > persistent across power loss. > > 3. Considering the different layers: > * the pmem and btt drivers blocks writes themselves, so it makes > sense for them to report ro at the pmem device layer. > * the nmem layer doesn't block writes, so shouldn't report anything > about them being restricted. > * the region layer doesn't block writes, so shouldn't report anything > about them being restricted.
The rationale for surfacing the read_only attribute at the region level, even though the region does not directly host I/O, is that regions host attributes that are common to all namespaces in that region. I see regions as distinct from the nmem level where there is not necessarily a direct correlation to namespaces, especially when nmems are optional in the device hierarchy. Regions are also the gateway interface for setting labels and aggregating state across several DIMMs. > * the region layer does need to pass along the NVDIMM state flags > to the pmem and btt drivers; read_only might not be the best name > as a user-visible attribute with that information. The state flags are ACPI specific, so we need to translate to something Linux generic when it moves to the libnvdimm sub-system. Read-only when the energy source fails is a preventative measure, the other state flags indicate that data has already been lost. > Some driver or software might find temporarily writing to those > locations in-place would be useful (e.g. run fsck before copying > the repaired filesystem content to another storage device), so we > shouldn't cut them off unnecessarily. The read_only attribute can be overridden, i.e. it's only a default value for safety. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
