excepted from kernel trap.
interview took place on Feb. 14.
1. 做事情需要有目的，不能光看代码，需要动手，这就需要一个理由。
2. 现在的Linux开发的情况和2000年也许又不相同了，很多大公司加入
进来了。加入这些公司去开发内核可能才是可行的路径。
3. Andrew Morton最后一句话说的好，“There are many things to do,
and Linux doesn't really need thousands of people adding even more code.”
更多的人需要去做测试，做QA，做Bug fix.
What advice can you offer to people just learning to become kernel hackers?
Andrew Morton:
There is a great amount to learn, and you don't learn it by reading the
code, or by reading the mailing list. You have to actually get in
there and change something. It's only when you try to do the hands-on
things that you realize how much you don't know.
And to get hands-on, you need a *reason*.
Profile the kernel, try to fix a performance bottleneck.
Pick a neglected bug report off the kernel list, work it with the
originator, see if you can fix it.
Pick a neglected device driver or filesystem, try to improve it.
There are new block and net driver interfaces coming through in 2.5 -
pick a driver for which you have hardware and take care of it.
Don't spout off opinions on the kernel mailing list.
Ignore what the kernel developers say about C++.
If you need to write, say, a net driver then don't! First, take an
existing one and make it beautiful, or more correct, or twice as fast,
or add a feature. Then take that knowledge to the new driver.
One hot tip: if you spot a bug which is being ignored, send a
completely botched fix to the mailing list. This causes thousands of
kernel developers to rally to the cause. Nobody knows why this
happens. (I really have deliberately done this several times. It works).
Write a really good filesystem and VM performance measurement suite
which models real-world workloads. The existing ones are almost
useless for this, and this gap in the toolset makes it much harder to
tune filesystems, and to discover performance improvements and
regressions.
There are many things to do, and Linux doesn't really need thousands
of people adding even more code.
