| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: [pcp] JSON PMDA, David Smith |
|---|---|
| Next by Date: | Re: [pcp] Hotproc fixes, Nathan Scott |
| Previous by Thread: | Re: [pcp] JSON PMDA, Nathan Scott |
| Next by Thread: | Re: JSON PMDA, Frank Ch. Eigler |
| Indexes: | [Date] [Thread] [Top] [All Lists] |