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

Robert P. J. Day rpjday at mindspring.com
Thu Mar 30 15:06:39 UTC 2006


On Thu, 30 Mar 2006, Bernhard Fischer wrote:

> On Thu, Mar 30, 2006 at 07:51:04AM -0500, Robert P. J. Day wrote:
> >
> >  NOTE:  i'm a bit iffy on some of the tests shown below.  for
> >instance, the test in mke2fs.c seems reasonable:
> >
> >if (linux_version_code && linux_version_code < KERNEL_VERSION(2,2,0))
> >
> >but the one in rmmod.c is a little curious:
> >
> >if (get_kernel_revision() <= KERNEL_VERSION(2,6,0))
> >                          ^^
> >
> >"<="??  that is, 2.6.0 and below should be treated differently from
> >2.6.1 and above?
>
> Very possible.

ok, i wasn't planning on changing that test, just wanted to see if
anyone else thought it looked a bit suspicious.  i'm leaving it as is
since it's clearly worked thus far.

> Why should we not test against experimental kernel releases resp.
> versions with odd minor numbers?

why *should* you?  put another way, what's the consensus of the kernel
development community towards dealing with issues related to
experimental kernels *once the next official release has come out*?

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?

seriously, i'm curious -- is there some benefit to getting down to
*that* level of detail for an experimental (and obsolete) kernel
release?

> >diff -pru busybox.orig/e2fsprogs/mke2fs.c busybox/e2fsprogs/mke2fs.c
> >--- busybox.orig/e2fsprogs/mke2fs.c	2006-03-29 07:43:43.000000000 -0500
> >+++ busybox/e2fsprogs/mke2fs.c	2006-03-30 07:30:30.000000000 -0500
> >@@ -33,6 +33,7 @@
> > #include "e2p/e2p.h"
> > #include "ext2fs/ext2fs.h"
> > #include "util.h"
> >+#include "platform.h"
>
> That include sounds wrong.
> e2fsbb.h includes libbb.h which includes platform.h

let me come back to this shortly.  for now, it's perfectly acceptable.

> >+#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?

rday



More information about the busybox mailing list