On Thu, Jan 6, 2022 at 12:19 PM Ira Weiny <[email protected]> wrote: > > On Mon, Jan 03, 2022 at 12:16:12PM -0800, Schofield, Alison wrote: > > From: Alison Schofield <[email protected]> > > > > Add libcxl APIs to create a new GET_PARTITION_INFO mailbox command, the > > command output data structure (privately), and accessor APIs to return > > the different fields in the partition info output. > > I would rephrase this: > > libcxl provides functions for C code to issue cxl mailbox commands as well as > parse the output returned. Get partition info should be part of this API. > > Add the libcxl get partition info mailbox support as well as an API to parse > the fields of the command returned. > > All fields are specified in multiples of 256MB so also define a capacity > multiplier to convert the raw data into bytes. > > > > > Signed-off-by: Alison Schofield <[email protected]> > > --- > > cxl/lib/private.h | 10 ++++++++++ > > cxl/libcxl.h | 5 +++++ > > util/size.h | 1 + > > cxl/lib/libcxl.c | 41 +++++++++++++++++++++++++++++++++++++++++ > > cxl/lib/libcxl.sym | 5 +++++ > > 5 files changed, 62 insertions(+) > > > > diff --git a/cxl/lib/private.h b/cxl/lib/private.h > > index a1b8b50..dd9234f 100644 > > --- a/cxl/lib/private.h > > +++ b/cxl/lib/private.h > > @@ -7,6 +7,7 @@ > > #include <cxl/cxl_mem.h> > > #include <ccan/endian/endian.h> > > #include <ccan/short_types/short_types.h> > > +#include <util/size.h> > > > > #define CXL_EXPORT __attribute__ ((visibility("default"))) > > > > @@ -104,6 +105,15 @@ struct cxl_cmd_get_health_info { > > le32 pmem_errors; > > } __attribute__((packed)); > > > > +struct cxl_cmd_get_partition_info { > > + le64 active_volatile_cap; > > + le64 active_persistent_cap; > > + le64 next_volatile_cap; > > + le64 next_persistent_cap; > > +} __attribute__((packed)); > > + > > +#define CXL_CAPACITY_MULTIPLIER SZ_256M > > + > > /* CXL 2.0 8.2.9.5.3 Byte 0 Health Status */ > > #define CXL_CMD_HEALTH_INFO_STATUS_MAINTENANCE_NEEDED_MASK BIT(0) > > #define CXL_CMD_HEALTH_INFO_STATUS_PERFORMANCE_DEGRADED_MASK BIT(1) > > diff --git a/cxl/libcxl.h b/cxl/libcxl.h > > index 89d35ba..7cf9061 100644 > > --- a/cxl/libcxl.h > > +++ b/cxl/libcxl.h > > @@ -109,6 +109,11 @@ ssize_t cxl_cmd_read_label_get_payload(struct cxl_cmd > > *cmd, void *buf, > > unsigned int length); > > struct cxl_cmd *cxl_cmd_new_write_label(struct cxl_memdev *memdev, > > void *buf, unsigned int offset, unsigned int length); > > +struct cxl_cmd *cxl_cmd_new_get_partition_info(struct cxl_memdev *memdev); > > why 'new'? Why not: > > cxl_cmd_get_partition_info() > > ?
The "new" is the naming convention inherited from ndctl indicating the allocation of a new command object. The motivation is to have a verb / action in all of the APIs. > > > +unsigned long long > > cxl_cmd_get_partition_info_get_active_volatile_cap(struct cxl_cmd *cmd); > > +unsigned long long > > cxl_cmd_get_partition_info_get_active_persistent_cap(struct cxl_cmd *cmd); > > +unsigned long long cxl_cmd_get_partition_info_get_next_volatile_cap(struct > > cxl_cmd *cmd); > > +unsigned long long > > cxl_cmd_get_partition_info_get_next_persistent_cap(struct cxl_cmd *cmd); > > These are pretty long function names. :-/ If you think those are long, how about: cxl_cmd_health_info_get_media_powerloss_persistence_loss The motivation here is to keep data structure layouts hidden behind APIs to ease the maintenance of binary compatibility from one library release and specification release to the next. The side effect though is some long function names in places. > I also wonder if the conversion to bytes should be reflected in the function > name. Because returning 'cap' might imply to someone they are getting the raw > data field. Makes sense.
