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