----- Original Message -----
> > -----Original Message-----
> > From: pcp-bounces@xxxxxxxxxxx [mailto:pcp-bounces@xxxxxxxxxxx] On Behalf Of
> > Nathan Scott
> > Sent: Wednesday, June 29, 2016 3:35 PM
> > To: Paul Smith <psmith@xxxxxxxxxx>; Ryan Doyle <rdoyle@xxxxxxxxxx>; Suyash
> > <dextrous93@xxxxxxxxx>; Lukas Berk <lberk@xxxxxxxxxx>
> > Cc: pcp developers <pcp@xxxxxxxxxxx>
> > Subject: [pcp] RFC: allowing longer metric and instance names in MMV(5)
> > format
> >
> > ...
>
> +1 ... good plan.
>
> I've tweaked the patch a little to make the language more consistent
> (attached) and have a couple of observations ...
>
Taa.
> 1. It does not appear that an Indoms2 section is needed (it was referred to
> but not defined).
Yeah, it is the same structure. I was thinking it will be helpful as a new
TOC type though, so that it's easy for pmdammv to know whether an instance2
or instance1 structure needs to be decoded. *shrug*, OTOH, maybe we should
just mandate that v2 mmv file version cannot contain v1 metric/instance TOC
entries? (currently v2 could have either/both - v1 is more compact, so I'd
be inclined to allow both still).
> 2. I don't recall what the "Unused padding (zero filled)" entries are for in
> the Instance and Metric entries, but could we (a) drop them from the
> Instance2 and Metric2 entries, and/or give them a better description in the
> man page (are they reserved for internal use, or some sort of backwards
> compatibility thing?)
My reading of it is that it was done to 64-bit align the fields following
afterward within those structures. Guess we'd need to prod Max to confirm
though.
cheers.
--
Nathan
|