[PATCH] uniform "kernel version" processing

[Robert P. J. Day]

On Thu, 18 May 2006, Bernhard Fischer wrote:

> On Thu, May 18, 2006 at 11:30:54AM -0400, Robert P. J. Day wrote:
> >
> >  1) single KERNEL_VERSION(a,b,c) macro in platform.h
> >  2) libbb/kernel_version.c now defines function
> >	get_linux_version_code()
> >
>
> As busybox.h already includes platform.h,

ah, you're right.  i *did* check for that, but didn't notice that it
includes it indirectly through libbb.h.  i can remove those
superfluous includes.  my fault.  i'll fix and resubmit.

> Renaming get_kernel_revision to get_linux_version_code is a bit odd,
> imo.

i did that because, first, "linux version code" is the correct
terminology, according to the kernel source itself, as shown in
include/linux/version.h:

#define UTS_RELEASE "2.6.16.16"
#define LINUX_VERSION_CODE 132624
#define KERNEL_VERSION(a,b,c) ...

and i was just trying to be consistent.  (calling it a "revision" is
just plain silly as that's not the terminology that's used in common
practice.)

> If there is need to check the revision on another platform, then why
> not #define get_kernel_revision(flavour,maj,min,patch) \
> 	get_##flavour##_kernel_revision(maj,min,patch)
>
> to be able to make the check a bit more platform agnostic?

i have no objection to that but, if you want to do that, then you
should also rename the macro from KERNEL_VERSION to
LINUX_KERNEL_VERSION and so on.  and while that is certainly a
reasonable topic for discussion, at the moment, there's no real
downside to cleaning up the code to *this* extent and giving longer
thought to what to do further down the road.  (at the moment, the
versioning is only meaningful in the context of linux so that's all
my patch was addressing.)

adjusted patch coming shortly.

rday