linux内核版本检查脚本 git后导致内核版本发生变化
2015-03-06 17:39
381 查看
我的修改方式是:vim scripts/setlocalversion
将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
全部注释掉,随即OK
http://blog.chinaunix.net/uid-22028680-id-3190615.html
在一次编译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
# <nico-linuxsetlocalversion -at- schottelius.org>.
#
通过阅读脚本,发现在脚本最后调用了一段程序
# 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是没有打开的,应该打开,接受linux的版本检查。原来如此,加号是这样加上去的。如果不想破坏这段代码,该如何去掉加号呢?那只有研究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。
将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
全部注释掉,随即OK
http://blog.chinaunix.net/uid-22028680-id-3190615.html
在一次编译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
# <nico-linuxsetlocalversion -at- schottelius.org>.
#
通过阅读脚本,发现在脚本最后调用了一段程序
# 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是没有打开的,应该打开,接受linux的版本检查。原来如此,加号是这样加上去的。如果不想破坏这段代码,该如何去掉加号呢?那只有研究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。
相关文章推荐
- 查看linux版本内核 Linux内核版本的变化
- Linux内核版本在不变升级,内核提供的API或符号可能也随之变化
- 查看linux版本内核 Linux内核版本的变化
- git获取Android指定版本的kernel内核
- 2.6内核同以前版本的绝大多数变化
- VC运行库版本不同导致链接.LIB静态库时发生重复定义问题的一个案例分析和总结
- 转载:VC运行库版本不同导致链接.LIB静态库时发生重复定义问题的一个案例分析和总结
- VC运行库版本不同导致链接.LIB静态库时发生重复定义问题的一个案例分析和总结
- WMF版本变化,导致Windows2008 R2 SP1上安装Lync失败
- 冷迁移(cold migration)vmware虚拟机MAC地址发生变化后的重置脚本
- [分享]Linux内核开发的版本控制工具Git中文教程
- struct sk_buff在内核2.6.24版本以后的扩展变化
- CLR版本变化导致的context的内容的变化
- VC运行库版本不同导致链接.LIB静态库时发生重复定义问题的一个案例分析和总结
- WMF版本变化,导致Windows2008 R2 SP1上安装Lync失败
- struct sk_buff在内核2.6.24版本以后的扩展变化
- 帮朋友做了一个IP发生变化后自动email通知的脚本。
- VC运行库版本不同导致链接.LIB静态库时发生重复定义问题的一个案例分析和总结
- liferay升级到5.1后类的路径发生变化导致的错误
- 检查内核版本的命令 linux