linux 检查内核版本号,linux内核版本本地版本号的检查

在一次编译kernel版本的时候我突然发现，“2.6.35.7“的内核版本编译成功后生成的版本号变成了“2.6.35.7+”，百思不得其解为什么后面会多一个加号。一步一步的查找，我发现了问题所在，原来问题出现在linux的版本控制这一块。

打开Makefile我们可以在文件的最上面可以发现

VERSION

= 2

PATCHLEVEL = 6

SUBLEVEL = 35

EXTRAVERSION = .7

NAME =

Yokohama

这些就是告诉我们内核版本的版本号，生成出来的版本号理论上不应带+号，但为什么带+号呢。继续往下看。

在编译成功后，我发现在kernel.release这个文件是生成的带有版本号的文件，打开后发现还是带+号，这肯定是生成这一个文件的脚本有问题所导致，继续查找，在主Makefile里面发现了生成kernel.release文件的脚本

#

Store (new) KERNELRELASE string in

include/config/kernel.release

include/config/kernel.release:

include/config/auto.conf FORCE

$(Q)rm -f $@

$(Q)echo

"$(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion

$(srctree))" >

$@这个脚本是从根目录调用了setlocalversion的脚本来生成版本号，并输出到kernel.release中的。打开setlocalversion发现这个文件为bash的脚本。文件头说明告诉我们这是一个增加本地版本号的脚本，那个+号可能就是通过这个脚本增加的本地版本号。

#!/bin/sh

#

#

This scripts adds local version information from the version

# control

systems git, mercurial (hg) and subversion (svn).

#

# If something goes

wrong, send a mail the kernel build mailinglist

# (see MAINTAINERS) and CC

Nico Schottelius

# .

#

通过阅读脚本，发现在脚本最后调用了一段程序

# scm version string if

not at a tagged commit

if test "$CONFIG_LOCALVERSION_AUTO" = "y";

then

# full scm version string

res="$res$(scm_version)"

else

# apped a plus sign if the

repository is not in a clean tagged

# state and  LOCALVERSION= is not

specified

if test "${LOCALVERSION+set}" != "set";

then

scm=$(scm_version --short)

res="$res${scm:++}"

fi

fi

如果CONFIG_LOCALVERSION_AUTO = y

这段程序会通过scm_version函数配置本地版本号。如果不为y，则会增加一个+号。我们目前的代码中CONFIG_LOCALVERSION_AUTO是没有打开的，应该打开，接受的版本检查。原来如此，加号是这样加上去的。如果不想破坏这段代码，该如何去掉加号呢？那只有研究scm_version函数了。函数中有一段如下函数

# Check for git and a git repo.

if head=`git rev-parse --verify

--short HEAD 2>/dev/null`; then                # If we are at a tagged commit

(like "v2.6.30-rc6"), we ignore

# it, because this version is

defined in the top level Makefile.

if [ -z "`git describe

--exact-match 2>/dev/null`" ]; then                        # If only the

short version is requested, don't bother

# running

further git commands

if $short;

then

echo

"+"

return

fi

# If we are past a tagged commit

(like

# "v2.6.30-rc5-302-g72357d5"), we pretty print

it.

if atag="`git describe 2>/dev/null`";

then

echo "$atag" | awk -F-

'{printf("-%05d-%s", $(NF-1),$(NF))}'                        # If we don't have

a tag at all we print -g{commitish}.

else

printf '%s%s' -g

$head

fi

fi                # Is

this git on svn?

if git config --get svn-remote.svn.url

>/dev/null; then

printf -- '-svn%s' "`git svn

find-rev $head`"

fi                # Update index only on r/w

media

[ -w . ] && git update-index --refresh

--unmerged > /dev/null                # Check for uncommitted

changes

if git diff-index --name-only HEAD | grep -v

"^scripts/package" \

| read dummy;

then

printf '%s' -dirty

fi                # All done with git

return

fi

他用bash判断语句来判断git rev-parse --verify --short

来判断当前是否是git版本库管理，并输出一个短的版本库HEAD

revision的短编码，如果存在则继续走。因为我的内核是在git版本库中的，因此肯定走这个地方。

接下来的代码

-z是判断字符串是否是0，是0则输出真。关键在git describe

--exact-match的执行结果。这一句是描述出tag的标识。如果没有tag就为空，那么整个if语句就为真，就会执行下去，下面的echo

“+”，这就会在版本号中输出一个+号。

如果我们在版本库中，git tag -a -m "v0.1" v0.1 后，我们在执行git describe

--exact-match这一句，发现输出的是我们的tag标识。那if语句就不成里了，就不会echo

“+”了。

但是问题又出现了，我发现，这样弄好后，版本号中出现了“2.6.35。7-dirty”，为什么呢？继续看上面的代码，printf

-dirty的地方进行了git diff的检查，也就是说我有修改过的，没有上传的文件。到此基本上原因全部查明，我把文件进行上传后，重新make

prepare后，生成额kernel.release果然正确了。

结论，linux对版本的管理相当严格，这也就让我们在进行代码管理中必须严格要求自己，比如发版本前，先检查是否还有修改为上传的文件，然后要在git版本库中打一个tag。