[PATCH] standardize on KERNEL_VERSION(a,b,c) test

[Rob Landley]

On Thursday 30 March 2006 10:06 am, Robert P. J. Day wrote:
> it's obvious that, over the lifespan of an experimental kernel (say
> 2.3.x), loads of new features are going to be introduced so that there
> will be a big jump between 2.2 and 2.4.  if you're testing for the
> existence of a new feature that was introduced somewhere in there, is
> there an inherent value in isolating *exactly* where it was
> introduced, or is it sufficient to just distinguish between 2.2.x and
> 2.4.x?

A while back loop.c had a bunch of tests for specific kernel versions halfway 
through development branches, and it broke very easily in a dozen different 
ways.  The current one just uses a quick test to see if the 64 bit API is 
supported and uses it if so.

Avoiding having to care is a big thing with me. :)

On a side note: testing for stuff back before 2.2 seems a bit strange.  Do we 
even _build_ on anything that old?  (Our oldest build environment we're 
testing against is Red Hat 9, with a 2.4 kernel.)

> > >+#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
> > >+
> >
> > Maybe this should be ifdef __linux__ or something like that?
>
> ok, i can add a corresponding test for that macro definition.  what's
> the standard test used here?

I think that anything that cares should probably involve platform.h somehow, 
and are going to annoy the MacOSX and libgloss people anyway.

> rday

Rob
-- 
Never bet against the cheap plastic solution.