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。