[Nagiosplug-devel] replacing common system calls with macros/inlines?

[sean finney]

hi ton,

On Wed, Mar 22, 2006 at 11:11:06AM +0000, Ton Voon wrote:
> I'm for this. My only concern is a consistent naming convention  
> (though I'm guilty of this).
> 
> I notice you are proposing an uppercase version. I would prefer a  
> prefix of np_.

my thought is that this muddies the water between two different
classes of functions.  the first (what was all caps above) are simple
macros/inline-wrappers with the same interface as an underlying system
call which just perform some standardized error checking.  the
second case (which includes functions such as np_net_connect and
np_runcmd) are specific interfaces we've designed to not
only catch errors from a syscall but also add a certain amount
of code/logic/functionality/convenience frequently used in plugins.
or maybe this is just me splitting hairs... after all i can't see
why it would be a Bad Thing to publish such functions in a
hypothetical API.

> I have a long term plan that "general" functions would move to an  
> installed dynamic library which the core C plugins would use. Then  
> also have something like apxs for Apache where a 3rd party could  
> create a C program which could then compile and link to this library.

i agree that this is a good idea... in fact istr bringing up the
issue some time back (back when we first started merging code
into the other np_foo functions).  i'd advise that before we do
this we fully think things out wrt the api's design, but
otherwise i'm all for it.

> Generally, a plugin goes through this sequence:
>   1) parse input parameters
>   2) get a numeric value, X, related to what is being checked
>   3) compare X against the specified thresholds

generally, yes, though the value is not always numeric (string
comparison, for example).  also, in some cases there are N:1
values:thresholds (check_disk), and in others N:N (check_tcp).  i'm not
sure if there are any 1:N or possibly more exotic mappings...

> For check_mysql_query, I've started to get some general functions to  
> parse thresholds (set_thresholds) and return status based on  
> thresholds (get_status). These general functions are tested with  
> libtap, so I think they are pretty reliable. These would be good  
> candidates for inclusion into your check_apt.c.

i'll take a look, but i think check_apt may end up not doing much wrt
numerical thresholds at all.  i spent a while  thinking about it earlier
today and it doesn't make much sense to me to have thresholds for the
number of packages available for an update.  what seems more reasonable
for such a plugin would be to check things like whether hte package is
a security update, whether the package is in a certain list of excluded
packages, whether apt-get successfully executed, etc.

however, i think probably 80% of the other existing code could make
use of numerical threshold functions, and it's possible we could
conjure a similar set of functions for strings/regexps.

> Also, what's the best way of documenting? List in the dev guidelines  
> the most useful functions?

perhaps a function:header mapping for the functions, so someone
could at a glance get an idea of the common functions?


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20060322/6ef8edfa/attachment.sig>