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

[Voon, Ton]

> -----Original Message-----
> From: Karl DeBisschop [mailto:karl at debisschop.net] 
> Sent: Tuesday, September 30, 2003 1:01 PM
> To: Ton Voon
> Cc: NagiosPlug Devel
> Subject: RE: [Nagiosplug-devel] RFC: OS specific ifdefs in 
> main plugin cod e
> 
> 
> 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.

Fair point - have added comments to code and also fixed a logic problem
which would have caused a problem on IRIX.

> 
> 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.

Agreed. I find it horrible.

> 
> > > 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).

Fair point - have indented the ifdefs better too.

> 
> 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. 

I think overall the plugins are getting much better. Thanks for your
comments.

Ton


This private and confidential e-mail has been sent to you by Egg.
The Egg group of companies includes Egg Banking plc
(registered no. 2999842), Egg Financial Products Ltd (registered
no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
carries out investment business on behalf of Egg and is regulated
by the Financial Services Authority.  
Registered in England and Wales. Registered offices: 1 Waterhouse Square,
138-142 Holborn, London EC1N 2NA.
If you are not the intended recipient of this e-mail and have
received it in error, please notify the sender by replying with
'received in error' as the subject and then delete it from your
mailbox.