pcp
[Top] [All Lists]

Re: [pcp] JSON PMDA

To: pcp@xxxxxxxxxxx
Subject: Re: [pcp] JSON PMDA
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Thu, 16 Apr 2015 09:11:49 +1000
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <1237712965.18667183.1429054767135.JavaMail.zimbra@xxxxxxxxxx>
References: <54F9F92D.4010202@xxxxxxxxxx> <448002717.7934024.1427683964254.JavaMail.zimbra@xxxxxxxxxx> <552699FE.7040801@xxxxxxxxxx> <2139482617.15593599.1428634701360.JavaMail.zimbra@xxxxxxxxxx> <552D6524.1030803@xxxxxxxxxx> <1237712965.18667183.1429054767135.JavaMail.zimbra@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
On 15/04/15 09:39, Nathan Scott wrote:
...
Its OK to extend the API/ABI, but not to break it.  Which should be all we
need to do here, I think.  Maybe see if we can reduce the range that those
cache.c interfaces accept - the two lines with "if (inst == 0x7fffffff) {"
there look promising.  If we had a h->maxinst there perhaps, instead of the
hard-coded 2^32-1 limit (may need to change the test to '>=' too) we might
be done and dusted here.  That'll turn out to be a gross oversimplification
I'm sure ... but maybe, just maybe it will work.

Can we tease out the h->maxinst part here?

How would that get set? A new "op" to pmdaCacheOp I presume (the ioctl() way of making ABI changes without breaking the ABI!).

But it would need to get preserved for persistent caches, and re-read when the cache was reloaded ... so that would be a VERSION bump (to 2) for the external file format and backwards compatibility code (set maxinst to 2^31-1 for VERSION 1).

Is this what was intended?

If so, it sounds OK to me, so far ...



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