2007.11.29
日常不注意,都没有想起看看linux 的SCM系统.
Quik link:
http://www.kernel.org/pub/software/scm/git/ git安装
http://www.kernel.org/pub/software/scm/git/docs/tutorial.html git官方教程
http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/ Torvalds 维护的内核树
http://bugzilla.kernel.org/ Linux 内核的bug tracking系统
http://kernel-perf.sourceforge.net/ Linux 性能测试组
http://lkml.org/ Linux 内核mail list
http://groups.google.com/group/linux.kernel/topics?lnk=li Linux.kenrel google 论坛
http://linux.bkbits.net/ Bitkeeper为linux提供的SCM系统
简单看看:
1.下载git并安装git
http://www.kernel.org/pub/software/scm/git/
2.clone一个到本地
git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
很大,完了之后可以到linux-2.6看看了
3.git-annotate
如
#git-annotate fs/buffer.c
commit number author date src code
4d141869 ( akpm 2002-05-28 02:12:50 +0000 1706)void unmap_underlying_metadata(....)
1c2bab0e ( torvalds 2002-02-05 17:40:40 +0000 1707){
1c2bab0e ( torvalds 2002-02-05 17:40:40 +0000 1708) struct buffer_head *old_bh;
1c2bab0e ( torvalds 2002-02-05 17:40:40 +0000 1709)
7079f897 ( mingo 2004-08-27 17:33:18 +0000 1710) might_sleep();
7079f897 ( mingo 2004-08-27 17:33:18 +0000 1711)
0d49bf15 ( akpm 2002-11-11 02:02:15 +0000 1712) old_bh = __find_get_block_slow(bdev, block, 0);
1c2bab0e ( torvalds 2002-02-05 17:40:40 +0000 1713) if (old_bh) {
08506315 ( akpm 2002-04-30 20:53:51 +0000 1714) clear_buffer_dirty(old_bh);
1c2bab0e ( torvalds 2002-02-05 17:40:40 +0000 1715) wait_on_buffer(old_bh);
08506315 ( akpm 2002-04-30 20:53:51 +0000 1716) clear_buffer_req(old_bh);
f59b316f ( patch 2002-02-05 20:24:46 +0000 1717) __brelse(old_bh);
1c2bab0e ( torvalds 2002-02-05 17:40:40 +0000 1718) }
可以看到这个函数的commit in 的人和日期
3.5 git-show
#git show 4d141869
commit 4d1418699875c48a5207083820f567771c7a6eed
Author: akpm <akpm>
Date: Tue May 28 02:12:50 2002 +0000
[PATCH] direct-to-BIO writeback
Multipage BIO writeout from the pagecache.
It's pretty much the same as multipage reads. It falls back to buffers
if things got complex.
The write case is a little more complex because it handles pages which
have buffers and pages which do not. If the page didn't have buffers
this code does not add them.
BKrev: 3cf2e7a24mMdOeknHlBKjmvd3lpi6g
diff --git a/fs/buffer.c b/fs/buffer.c
index 96d2b68..68349fb 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1448,11 +1448,11 @@ EXPORT_SYMBOL(create_empty_buffers);
* wait on that I/O in bforget() - it's more efficient to wait on the I/O
* only if we really need to. That happens here.
*/
-static void unmap_underlying_metadata(struct buffer_head *bh)
+void unmap_underlying_metadata(struct block_device *bdev, sector_t block)
{
struct buffer_head *old_bh;
- old_bh = __get_hash_table(bh->b_bdev, bh->b_blocknr, 0);
+ old_bh = __get_hash_table(bdev, block, 0);
if (old_bh) {
#if 0 /* This happens. Later. */
if (buffer_dirty(old_bh))
@@ -1548,7 +1548,8 @@ static int __block_write_full_page(struct inode *inode,
if (buffer_new(bh)) {
/* blockdev mappings never come here */
clear_buffer_new(bh);
:
4.git-log
#git-log fs/buffer.c
#git-log -p fs/buffer.c
然后键入 '/'搜索 1c2bab0e可以看到相关的log信息
commit 1c2bab0e9e0648cae8a4a0bd514eeef77341bd26
Author: torvalds <torvalds>
Date: Tue Feb 5 17:40:40 2002 +0000
Import changeset
BKrev: 3c601918i-Rse1XOIZxu4fPHUrTmmA
(始的原因还是不易得到)
5. 官方的git 教程
我就不在这里弄斧了.
http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
6. 其他常用命令
git-tag
git-diff v2.4.0 fs/buffer.c
a tag current file
git log v2.5..v2.6 # commits between v2.5 and v2.6
git log v2.5.. # commits since v2.5
git log --since="2 weeks ago" # commits from the last 2 weeks
git log v2.5.. Makefile # commits since v2.5 which modify
参考资料: (google 一下吧,免得日后链接失效,这里没更新)
<<Introduction to linux kernel development process>> Written by Paolo Ciarrocchi, November 2005
原文拷贝:
Introduction to linux kernel development process
(Written by Paolo Ciarrocchi, November 2005)
(http://paolociarrocchi.googlepages.com/)
---- Overview ----
Linux kernel development process is quite complex and not very well documented
so I decided to try to summarize it in the hope to be useful for the community.
2.6.x kernels are the base stable releases released by Linus.
The highest numbered release is the most recent.
If regressions or other serious flaws are found then a -stable fix patch
will be released (see below) on top of this base. Once a new 2.6.x base
kernel is released, a patch is made available that is a delta between the
previous 2.6.x kernel and the new one.
--- 2.6.x kernels ---
2.6.x kernels are maintained by Linus Torvalds,
it's development is as follow:
- As soon a new kernel is released a two weeks windows is open, during
this period of time maintainers can submit big diffs to Linus, usually
the patched sited in -mm kernels for a few weeks.
Preferred way to submit big changes is using GIT
(more information about GIT at http://git.or.cz/ and
http://www.kernel.org/pub/software/scm/git/docs/tutorial.html).
- After two weeks a -rc1 kernel is released and now is possible to
push only patches that do not include new functionalities that could
affect the stability of the whole kernel. Please note that a whole
new driver (or filesystem) might be accepted
after -rc1 because there is no risk of causing regressions with
such a change
- A new -rc is released whenever Linus deems the current git
(the kernel's source management) tree to be in a reasonably sane state
adequate for testing. The goal is to release a new -rc kernel every week.
- Process continues until the kernel is considered "ready", the
process should last around 6 weeks ( 6 kernels per year should be
released) an usually includes 4/5 rc releases.
There a numbers of tools used by the community to measure the quality and the
performance of a kernel.
A couple of examples are:
- kernel-perf.sourceforge.net
Copy and paste from the project description:
"We are a group of dedicated Linux kernel engineers taking on the challenge
of testing the Linux kernel. In order to track performance, we are running
a large set of benchmarks covering core components of the Linux kernel
(virtual memory management, I/O subsystem, process scheduler, file system,
network, device driver, etc). Benchmarks are run on a variety of platforms
every week, testing the latest snapshot of Linus' git development tree.
Comprehensive performance data from our tests will be hosted here for
easy access."
- bugzilla.kernel.org
It's the official bugzilla instance used as an online kernel bug tracking.
Users are invited to report all the bugs they hit using this tool.
But it's worth to mention what Andrew Morton wrote on lkml:
"Nobody knows when a kernel will be released, because it's released
according to perceived bug status, not according to a preconceived
timeline."
--- 2.6.x.y kernels, a.k.a -stable ---
Kernels with 4 digit versions are -stable kernels. They contain small(ish)
critical fixes for security problems or significant regressions discovered
in a given 2.6.x kernel.
This is the recommended branch for users who want the most recent stable
kernel and are not interested in helping test development/experimental
versions.
If no 2.6.x.y kernel is available, then the highest numbered 2.6.x kernel is
the current stable kernel.
2.6.x.y are maintained by the "stable" team (stable at kernel dot
org), are released almost every week.
Rules on what kind of patches are accepted, and what ones are not, into
the "-stable" tree:
- It must be obviously correct and tested.
- It can not bigger than 100 lines, with context.
- It must fix only one thing.
- It must fix a real bug that bothers people (not a, "This could be a
problem..." type thing.)
- It must fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short,
something critical.
- No "theoretical race condition" issues, unless an explanation of how
the race can be exploited.
- It can not contain any "trivial" fixes in it (spelling changes,
whitespace cleanups, etc.)
- It must be accepted by the relevant subsystem maintainer.
- It must follow Documentation/SubmittingPatches rules.
Procedure for submitting patches to the -stable tree:
- Send the patch, after verifying that it follows the above rules, to
stable@kernel.org.
- The sender will receive an ack when the patch has been accepted into
the queue, or a nak if the patch is rejected. This response might
take a few days, according to the developer's schedules.
- If accepted, the patch will be added to the -stable queue, for review
by other developers.
- Security patches should not be sent to this alias, but instead to the
documented security@kernel.org.
Review cycle:
- When the -stable maintainers decide for a review cycle, the patches
will be sent to the review committee, and the maintainer of the
affected area of the patch (unless the submitter is the maintainer of
the area) and CC: to the linux-kernel mailing list.
- The review committee has 48 hours in which to ack or nak the patch.
- If the patch is rejected by a member of the committee, or linux-kernel
members object to the patch by bringing up issues that the maintainer
and members did not realize, the patch will be dropped from the
queue.
- At the end of the review cycle, the acked patches will be added to
the latest -stable release, and a new -stable release will happen.
- Security patches will be accepted into the -stable tree directly from
the security kernel team, and not go through the normal review cycle.
Contact the kernel security team for more details on this procedure.
Review committee:
- This will be made up of a number of kernel developers who have
volunteered for this task, and a few that haven't.
--- The -mm kernels ---
These are experimental kernels released by Andrew Morton.
The -mm tree serves as a sort of proving ground for new features and other
experimental patches.
Once a patch has proved its worth in -mm for a while Andrew pushes it on to
Linus for inclusion in mainline.
Although it's encouraged that patches flow to Linus via the -mm tree, this
is not always enforced.
Subsystem maintainers (or individuals) sometimes push their patches directly
to Linus, even though (or after) they have been merged and tested in -mm (or
sometimes even without prior testing in -mm).
This branch is in constant flux and contains many experimental features, a
lot of debugging patches not appropriate for mainline etc and is the most
experimental of the branches described in this document.
These kernels are not appropriate for use on systems that are supposed to be
stable and they are more risky to run than any of the other branches (make
sure you have up-to-date backups - that goes for any experimental kernel but
even more so for -mm kernels).
These kernels in addition to all the other experimental patches they contain
usually also contain any changes in the mainline -git kernels available at
the time of release.
The -mm kernels are not released on a fixed schedule, but usually a few -mm
kernels are released in between each -rc kernel (1 to 3 is common).
--- The -git kernels ---
These are daily snapshots of Linus' kernel tree (managed in a git
repository, hence the name).
These patches are usually released daily and represent the current state of
Linus' tree. They are more experimental than -rc kernels since they are
generated automatically without even a cursory glance to see if they are
sane.
I hope you enjoy reading this article and I really deserve
special thanks to Tony Luck and Jesper Juhl for their suggestions!!
Part of this article is from the document written by Jesper Juhl,
you can find it here:
http://sosdg.org/~coywolf/lxr/source/Documentation/applying-patches.txt
|