On Wed, Jan 30, 2019 at 2:59 AM Oliver O'Halloran <[email protected]> wrote: > > Newer kernels provide the "supported_alignments" sysfs attribute that > indicates what alignments can be used with a PFN or DAX namespace. This > patch adds the plumbing inside of libndctl to allow users to query this > information through using: > ndctl_{dax|pfn}_get_supported_alignment(), and > ndctl_{dax|pfn}_get_num_alignments() > > Signed-off-by: Oliver O'Halloran <[email protected]> > --- > v5: Fixed comment wording > > v4: Changed return code of ndctl_pfn_get_supported_alignment from -1 to > -1 to -EINVAL. > > Reworded comment about why we default to 4K and 2M alignments when > the sysfs attribute is missing. > > Shuffled around prototypes in ndctl.h. > > 80 char compliance fixes. > > rebased onto pending branch > > v3: Changed the return type of the *_get_supported_alignment() functions > to unsigned long to match the existing *_get_alignment() functions.
After playing with this facility in the v64 release I think it needs a redo for the following reasons: * It's a bit too chatty and redundant even behind a "-v" because all namespaces share the same attributes, * this breaks the long standing, but admittedly not documented, style guideline that all json values have an associated key, even if the key is effectively just a generic index value. There are common methods to enumerate the key space, but key-less arrays need to be handled explicitly. * It's the only field in the json that does not reflect the current state of a device. For this reason I think it should be moved behind a --capabilities flag and a named "capability" object as a child of a region. This would also help with the redundant "supported" prefix. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
