pcp
[Top] [All Lists]

Re: JSON PMDA

To: David Smith <dsmith@xxxxxxxxxx>
Subject: Re: JSON PMDA
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Tue, 28 Apr 2015 15:59:57 -0400
Cc: Nathan Scott <nathans@xxxxxxxxxx>, pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <553F9968.4070509@xxxxxxxxxx> (David Smith's message of "Tue, 28 Apr 2015 09:30:00 -0500")
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> <5536C228.8010001@xxxxxxxxxx> <1344441557.4430503.1429658863072.JavaMail.zimbra@xxxxxxxxxx> <553F9968.4070509@xxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
dsmith wrote:

> [...]
> I wonder if it wouldn't make sense to define something like the
> following instead:
>
>     int pmdaCacheOp2(pmInDom indom, int op, unsigned long val);
>
> with an associated op of PMDA_CACHE2_RESIZE. That would give more room
> for the addition of future operations.

FWIW, I'm not a fan of ioctl-like functions like this.  They provide
apparent API/ABI stability but not actual API/ABI stability.  (There
would be no way to verify op values or appropriateness of val for each
op, etc.)  Adding new functions as first class functions is easy.


- FChE

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