[Nagiosplug-devel] RFC: OS specific ifdefs in main plugin cod e

[Karl DeBisschop]

On Tue, 2003-09-30 at 03:54, Voon, Ton wrote:

> > What I don't like is use of targets like #ifdef _AIX or #ifdef sun --
> > for instance, SGI IRIX also has a swap command ...

> The reason for the sun specific code is that swap -l does not report
> "allocated but not used" swap, thus giving "wrong" results on free
> (available) swap. This is only available with swap -s. There was a thread on
> this about 9 months back.

I think this should be in the comments in the code - few if any people
will remember why the sun implementation was called out a year from now.

Will 'swap -s' work with IRIX?

> The trouble with IRIX which "also has a swap command with very similar
> syntax" is that the syntax is similar but not the same. So we would have to
> have ./configure work in parsing the output differently. But sometimes it is
> more than just the sscanf order: there is also if there is a header line, if
> the syntax returns MBs or bytes or percentage, if the results are for free,
> used or total.

I understand this, and I accept that it is a reason for needing to make
the sort of #ifdef that you have done. (Note that above, I said I don't
like this style, I was careful not to say this style should not be used
-- sometimes it must be. But there are drawbacks, and I think we should
be careful using it)

> I guess these could be abstracted out to a generic function, but then the
> parameters to this function will probably need to be written very
> "code-like", so why not use code?

I agree - to move the #ifdef to some abstratcted function is window
dressing if you still use the same OS-based distinction.

FWIW, personally, I'm on the fence on this particilar implementation.
I'd like to see fewer OS-specific ifdefs, but I trust that you've looked
into it and it's not worth doing in this case.

> I agree, but these are not always readily available hence the hackery.
> Eventually, I guess nagiosplug is basically a command-line way of getting a
> common result from all OSes.

True. But experience has shown that grepping a command-line utility from
the OS is about the worst way to go about doing that.

> > 
> > Certainly we can write a check_icmp, and probably should. If we can
> > identify an apporpriate API for swap and procs, we should do the same
> > for them. If not, I am much more ready to accept OS-specific 
> > ifdefs for
> > procs than I am for swap. There are only a handful of swap variants.
> 
> I only have Solaris, AIX and Darwin knowledge and they all handle swap
> differently (Darwin doesn't even preallocated swap space - it just
> dynamically grows).

I have access to Solaris, FreeBSD, SGI (and Linux) - maybe if we add
that in, we can at least document what the variations are.

> check_procs doesn't have any ifdefs, maybe because the abstration is
> better/easier. Even so, I've had to add in extra variables to ./configure
> like number of columns to get round some inconsistencies (AIX's ps does not
> have an RSS field).

If it is easier, it's not by much. The test block is cryptic, order
dependent, and essentially impossible to systematically debug.

> > AFAICT, if there ar n varieties of Unix, there must be n+1 
> > varieties of the ps command.
> 
> If we continue with the ifdef method, in future we could abstract out as we
> understand the different cases better.

Yes.

Again, if you feel we should go this route at present, I respect that.
My opinion on the policy we should take is that we should use
OS-specific ifdefs as little as practically possible, implementation
choices should be left to the implementor.

I do think better in-line comments about what led you to this approach
would be worthwhile (if you do that, I noticed not all of your indents
are consistent with the surrounding #ifdef indentation).

I also like the idea that we may be able to go back and remove some
OS-specific #ifdefs in favor of generic code. But I don't want to slow
down release-realted work with the effort to move to the generic form. 

--
Karl