| 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> |
|---|---|---|
| ||
| Previous by Date: | pcp updates: merges, docs, qa, Nathan Scott |
|---|---|
| Next by Date: | pmda leftover processes after pmda removal, Marko Myllynen |
| Previous by Thread: | RE: [pcp] Multi-archive Contexts Getting Close to Merge, Ken McDonell |
| Next by Thread: | pmdaslurm updates, Martins Innus |
| Indexes: | [Date] [Thread] [Top] [All Lists] |