pcp
[Top] [All Lists]

Re: [pcp] Multi-archive Contexts Getting Close to Merge

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>, Dave Brolley <brolley@xxxxxxxxxx>
Subject: Re: [pcp] Multi-archive Contexts Getting Close to Merge
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Sun, 28 Feb 2016 22:50:15 -0500 (EST)
Cc: PCP Mailing List <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <001a01d170d1$c8cb7db0$5a627910$@internode.on.net>
References: <56CCBA62.3050702@xxxxxxxxxx> <001a01d170d1$c8cb7db0$5a627910$@internode.on.net>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: AQFK1HqbLxipoIl/C5DceElHoM7hyKBL+IJg381kAB8=
Thread-topic: Multi-archive Contexts Getting Close to Merge

----- Original Message -----
> [...]
> > *   Whether to restrict pmdumplog(1) and pmlogcheck(1) to single
> > archive contexts.
> 
> I'd be happy to see these restricted in the first instance, and then
> revisited once we've shaken the core functionality down.

FWIW, one possible approach for implementing this would be to use the
__pmSetInternalState interface.  If we tweak the semantics argument to
allow a bitfield, we could perhaps add a ...

#define PM_STATE_APPL   0x0
#define PM_STATE_PMCS   0x1
#define PM_STATE_ONELOG 0x2

... without any API/ABI disturbance.  Obviously, that flag would need
to be set by tools opting-in to that mode, and before they create any
contexts.  I'm slightly surprised that pmdumplog and pmlogcheck aren't
setting PM_STATE_PMCS already, since they're not derived/anon metrics
users.  (is that an oversight Ken?  pmlogreduce & pmlogextract use it)

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>