能够方便地移植到各个硬件平台，kbuild也必须很容易添加对某个新的平台的支持，同时上层的Makefile不需要做大的改动。
2.Linux下有众多驱动设备。它们的Makefile希望能够尽可能简洁。简洁到只要指定要编译的.o文件就行。（这方面kbuild定义了很多有用的变量如obj-m obj-y,-objs等等，用户只要为这些变量赋值，kbuild会自动把代码编译到内核或者编译成模块）
3.要有方便的可定制性。很多参数可以让用户指定。这方面kbuild也提供了大量的变量如EXTRA_CFLAGS，用户如果想include自己的头文件或者加其它编译参数，只要设置一下EXTRA_CFLAGS就可以。
4.有能力递归地调用Makefile。因为内核是一个庞大的软件。它的源代码的目录层次很深。要提供一种简洁的机制，使上层的Makefile能方便地调用下层的Makefile。在这过程中，面向对象的思想也许值得借鉴。
5.在配置内核时，要提供友好的用户界面。这方面kbuild也提供了不少工具，如常用的make menuconfig等等。
我们完全可以把kbuild想象成一个类库，它为普通的内核开发人员提供了接口（obj-m obj-y EXTRA_CFLAGS等等），为用户提供了定制工具（make menuconfig）
一般情况下是不需要知道具体的编译顺序的。除了在个别情况下，如do_initcalls()中就和函数在tcall.init section中的顺序有关。不过喜欢寻根究底的我，还是想理一下编译内核时几个常用的命令，如make bzImage,make menuconfig等等，进而了解kbuild的架构。先看make bzImage吧。
以前我一直对它的格式表示奇怪，现在很清楚了，它们是作为makefile的一部分，通过读取CONFIG_XXX的值就可以知道他们是作为模块还是作为内核的一部分而编译的。
。正如它的文件名所示，这类似于一个库文件。它负责对obj-m obj-y,-objs等变量进行加工处理。从中提取出subdir-ym等变量，这是个很重要的变量，记录了需要递归调用的子目录。以后递归调用Makefile全靠它了。这里也充分体现了GNU make对字符串进行操作的强大功能。
所以，当用户在源代码目录下执行make bzImage。make会检查bzImage的依赖目标，然后不停地递归调用各个Makefile，最终生成一个bzImage文件。
如果我们换个角度，还可以归纳出不少有趣的东西。如果把make看成是一种脚本语言，那么Makefile就是代码。make就是解释器。make里也有函数，也有变量。通过定义目标，可以实现类似于函数的效果。而目标之间的依赖关系则类似于函数内部再调用其它函数。
2.要使变量的作用域扩展到整个make命令的执行过程（包括递归调用的其它Makefile），需要使用export命令。
