基于hello.c的Makefile：（在我的《Linux驱动—模块化编程》）
执行模块的Makefile要进来 三次！！！！！！！！
第一次：
KERNELRELEASE是内核源码树的一个变量，我们第一次敲make的时候，其实它是没有的,为空，逗号右边也没有填东西，也为空
故而 ifneq ($(KERNELRELEASE),)的结果“真”，执行 else 的语句:
进入else后：
KDIR是一个内核的环境变量，绝对路径 ，“:=”为赋值变量
$(shell uname -r)取字符串拼接起来
让我们来看一看 uname -r是什么命令：
让我们进入/lib/modules/5.4.0-77-generic/build这个目录下：
我们看到这里面非常像我们内核树目录，这里面就放我们编译生成一个内核目标文件所依赖的一个内核
PWD :=$(shell pwd)
PWD保存make执行的路径
接下来执行 
（make前面一定是tab键）
make -C $(KDIR) M=$(PWD) modules
$(KDIR)：进入KDIR（内核源码树）去Makefile M=$(PWD)：会到这个目录来找目标文件（例如.c文件）
编译内核有两种方式：
①make … modules：将一个驱动文件独立于内核之外编译，再动态加载进去（此处是这种）
②也可以把编译进内核镜像里
我们来看最顶层的Makefile里的内容：
此处我们对应的就是这个命令
注意：不会顺序执行clean
第二次
在第一次执行完make -C $(KDIR) M=$(PWD) modules后，因为M=$(PWD)，所以又进来这个目录一次，这次又执行Makefile，这是第二次进入
此次进入后KERNELRELEASE就有值了（进入了一次顶层Makefile，在里面给KERNELRELEASE赋了值）
此时ifneq ($(KERNELRELEASE),)就成立
执行obj-m:=hello.o
“obj-m”：生成模块化目标文件
“:=hello.o”：依赖于hello.o
这个时候它就知道需要将hello.c编译成hello.o，编译好后就又出来了
第三次
从第二次出来以后，顶层Makefile又会去执行一个链接操作，这个链接操作又会再次进入这个目录下面，它会把我们刚刚生成的hello.o文件和其他的一些依赖文件从内核路径/lib/modules/5.4.0-77-generic/build链接成一个hello.ko文件
我们来验证一下
最后
first：进入内核源码树、获取路径
second：第一次结束时进入了顶层Makefile，顶层Makefile再次进入路径获取生成模块的.c文件，编译为.o
third：顶层Makefile将所需要的依赖链接成.ko文件
这个图好像不太生动，嗯。。。。。。放这里装杯吧