From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Marzinski Subject: Re: [PATCH v2 10/17] libmultipath: add code to get vendor specific vpd data Date: Mon, 10 Feb 2020 14:49:42 -0600 Message-ID: <20200210204942.GD30153@octiron.msp.redhat.com> References: <1580929100-32572-1-git-send-email-bmarzins@redhat.com> <1580929100-32572-11-git-send-email-bmarzins@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com Content-Disposition: inline To: Martin Wilck Cc: "dm-devel@redhat.com" List-Id: dm-devel.ids On Mon, Feb 10, 2020 at 02:49:38PM +0000, Martin Wilck wrote: > On Wed, 2020-02-05 at 12:58 -0600, Benjamin Marzinski wrote: > > This adds the wildcard 'g' for multipath and path formatted printing, > > which returns extra data from a device's vendor specific vpd > > page. The > > specific vendor vpd page to use, and the vendor/product id to decode > > it > > can be set in the hwentry with vpd_vendor_pg and vpd_vendor_id. It > > can > > be configured in the devices section of multipath.conf with the > > vpd_vendor parameter. Currently, the only devices that use this are > > HPE > > 3PAR arrays, to return the Volume Name. > >=20 > > Signed-off-by: Benjamin Marzinski > > --- > > libmultipath/config.c | 2 ++ > > libmultipath/config.h | 1 + > > libmultipath/dict.c | 38 ++++++++++++++++++++++++++++++++++++ > > libmultipath/discovery.c | 40 > > +++++++++++++++++++++++++++++++++++++- > > libmultipath/hwtable.c | 1 + > > libmultipath/print.c | 25 ++++++++++++++++++++++++ > > libmultipath/propsel.c | 18 +++++++++++++++++ > > libmultipath/propsel.h | 1 + > > libmultipath/structs.h | 15 ++++++++++++++ > > multipath/multipath.conf.5 | 8 ++++++++ > > 10 files changed, 148 insertions(+), 1 deletion(-) > >=20 > > diff --git a/libmultipath/structs.h b/libmultipath/structs.h > > index 1c32a799..6c03ee5d 100644 > > --- a/libmultipath/structs.h > > +++ b/libmultipath/structs.h > > @@ -21,6 +21,7 @@ > > #define HOST_NAME_LEN=09=0916 > > #define SLOT_NAME_SIZE=09=0940 > > #define PRKEY_SIZE=09=0919 > > +#define VPD_DATA_SIZE=09=09128 > > =20 > > #define SCSI_VENDOR_SIZE=099 > > #define SCSI_PRODUCT_SIZE=0917 > > @@ -221,6 +222,18 @@ enum all_tg_pt_states { > > =09ALL_TG_PT_ON =3D YNU_YES, > > }; > > =20 > > +enum vpd_vendor_ids { > > +=09VPD_VP_UNDEF, > > +=09VPD_VP_HP3PAR, > > +=09VPD_VP_ARRAY_SIZE, /* This must remain the last entry */ > > +}; > > + > > +struct vpd_vendor_page { > > +=09int pg; > > +=09const char *name; > > +}; > > +extern struct vpd_vendor_page vpd_vendor_pages[VPD_VP_ARRAY_SIZE]; > > + > > struct sg_id { > > =09int host_no; > > =09int channel; > > @@ -255,6 +268,7 @@ struct path { > > =09char rev[PATH_REV_SIZE]; > > =09char serial[SERIAL_SIZE]; > > =09char tgt_node_name[NODE_NAME_SIZE]; > > +=09char vpd_data[VPD_DATA_SIZE]; >=20 >=20 > Hm, 128 more bytes per path for a rarely-used property... do we need to > store this in "struct path"? Can't we simply fetch that information > when someone requests it with the %g format wildcard? It doesn't matter > much today as "struct path" is really thick already, but I have hopes > to make it a bit leaner some day. Well, the thought was that this information (which should help map the path to a physical array) would most often be wanted when things were going badly, and you might not be able to access the device. -Ben > Regards > Martin >=20 > --=20 > Dr. Martin Wilck , Tel. +49 (0)911 74053 2107 > SUSE Software Solutions Germany GmbH > HRB 36809, AG N=FCrnberg GF: Felix > Imend=F6rffer >=20