kernel versions, revisions, codes and pedantic stuff like that

Robert P. J. Day rpjday at mindspring.com
Thu May 18 14:53:00 UTC 2006


  i plan on re-submitting my patch to make consistent the terminology
referring to kernel "versions", but we need to agree on what that
consistency should be.

  currently, there are three different macros for the same job:

	KERNEL_VERSION(2,2,0)
	KERNEL_RELEASE(2,1,0)
	MAKE_VERSION(2,1,117)

all of which do the same thing.  to be consistent with the kernel
source itself, how about we go with

  #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))

in platform.h and everyone who needs that can include platform.h?

 in addition, we can agree on terminology.  a "release" would be a
character string like "2.6.16.15", while invoking the KERNEL_VERSION
macro returns to you a "linux version *code*" -- pretty much the way
it's defined now in BB code.

  finally, the source file libbb/kernel_version.c has an acceptable
name, but the function contained therein really shouldn't then be
called "get_kernel_revision".  it would make far more sense to rename
that function to "get_linux_version_code" so that everyone is speaking
the same language.

  if no one objects, i can submit a patch to do all of the above.

rday



More information about the busybox mailing list