yaffs2最新源码的debug记录

昨天，我打算把最新的yaffs2源码移植到linux-3.4.2中去。先使用git命令去获取最新源码：git clone git://www.aleph1.co.uk/yaffs2 。然后进入目录，运行脚本：“./patch-ker.sh c m ../linux-3.4.2”，把yaffs源码添加到内核树中去。接着是make menuconfig以及make uImage。最后新的uImage编译出来了，可是当我把uImage放到开发板上去运行的时候，发现最终无法挂接 NAND Flash 上的根文件系统。出错信息如下：

Unable to handle kernel paging request at virtual address 636f6c6a
pgd = c0104000
[636f6c6a] *pgd=00000000
Internal error: Oops: 3 [#1] ARM
Modules linked in:
CPU: 0    Not tainted  (3.4.2 #4)
PC is at yaffs_getxattr+0x20/0x90
LR is at get_vfs_caps_from_disk+0x5c/0xf8
pc : [<c024e07c>]    lr : [<c0266f0c>]    psr: 60000013
sp : c381fe78  ip : c024e05c  fp : 00000000
r10: c3401d18  r9 : c381c660  r8 : c05a9d0c
r7 : c381fe94  r6 : 00000014  r5 : 636f6c62  r4 : c34057f0
r3 : 00000014  r2 : f0000010  r1 : c04f3a18  r0 : c3401d18
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: c000717f  Table: 30104000  DAC: 00000017
Process swapper (pid: 1, stack limit = 0xc381e270)
Stack: (0xc381fe78 to 0xc3820000)
fe60:                                                       c34057f0 c3401d18
fe80: c381fec4 c3a30660 c381e000 c0266f0c 00000020 c3802be0 00000000 c3800ae0
fea0: 00000000 c3a7b5f8 c3a30660 c381cc60 000081ed c0267030 c381cc90 c3a7ade4
fec0: c3a7b5f8 00000000 00000000 00000000 00000000 00000000 c3a7ade0 00000000
fee0: c3a30660 c3a30660 c34057f0 000081ed c3a30660 c0595060 c381ff50 c0594fd8
ff00: 00000000 c0197668 00000001 c381e000 00000002 c381e000 c00802c2 c0197f08
ff20: c381ae84 00000000 c380e3b0 c00802c2 c0594fd8 c0595060 c05c0900 0000009c
ff40: c05611ac c0583038 00000000 c0118360 00000000 00000000 00000000 00000000
ff60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ff80: 00000000 00000000 00000000 00000000 00000000 00000000 c0589d38 c0594fd8
ffa0: c05c0900 00000008 c05c0900 0000009c c05611ac c0108994 c0589d38 c0583034
ffc0: 00000008 c0561384 00000007 00000007 c05611ac 00000000 00000000 c0561218
ffe0: c0116468 00000013 00000000 00000000 00000000 c0116468 33ce33fd 73cd7fff
[<c024e07c>] (yaffs_getxattr+0x20/0x90) from [<c0266f0c>] (get_vfs_caps_from_disk+0x5c/0xf8)
[<c0266f0c>] (get_vfs_caps_from_disk+0x5c/0xf8) from [<c0267030>] (cap_bprm_set_creds+0x88/0x400)
[<c0267030>] (cap_bprm_set_creds+0x88/0x400) from [<c0197668>] (prepare_binprm+0xb0/0x114)
[<c0197668>] (prepare_binprm+0xb0/0x114) from [<c0197f08>] (do_execve+0x25c/0x368)
[<c0197f08>] (do_execve+0x25c/0x368) from [<c0118360>] (kernel_execve+0x34/0x84)
[<c0118360>] (kernel_execve+0x34/0x84) from [<c0108994>] (init_post+0xfc/0x138)
[<c0108994>] (init_post+0xfc/0x138) from [<c0561384>] (kernel_init+0x16c/0x1bc)
Code: e1a06003 e3120002 e591513c 1a00000f (e5954008) 
---[ end trace da2b377cb1c8f281 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

似乎是yaffs_getxattr()这个函数有问题。

我回去看了一下mkae uImge编译过程输出的信息，发现有几个warning，出现在yaffs_vfs.c和yaffs_guts.c这两个文件里。

到yaffs_vfs.c出现warning的行去，发现果然是yaffs_getxattr()这个函数的问题。文件中函数的定义是这样的：

看来是根据YAFFS_NEW_XATTR这个宏去分支，于是搜索这个宏

看来它是根据内核版本来定义的：内核版本大于等于4.8.0时，这个宏为1，否则为0。

从上面可以看出，这个宏是被定义了的。也就是说对于yaffs_getxattr()这个函数的定义，是不会选择“#else”这个分支的，即它被定义为：

static int yaffs_setxattr(struct dentry *dentry, struct inode *inode, const char *name, const void *value, size_t size, int flags)

在这个文件中，函数的指针被传给了inode_operations 结构体的getxattr成员：

但是，这个成员在3.4.2内核的fs,h头文件中的原型却是：

ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t);

也就是说，前文所讲的对于yaffs_getxattr()的定义，“#else”这个分支才是和3.4.2内核相符合的。这也是为什么warnimng中会出现“incompatible pointer types”这样的信息的原因。

要使用这个分支，我们只需要简单地做一下修改即可。

原文：#ifdef YAFFS_NEW_XATTR

改为：#if (YAFFS_NEW_XATTR > 0)

这样的话，对于3.4.2内核的情况（版本号小于4.8.0），YAFFS_NEW_XATTR宏展开为0，不符合#if的条件，就进入#else了。

出现在yaffs_guts.c中的那个warning，是由于其中result这个变量没有初始化引起的。

虽然不影响正常使用，我还是做了简单的修改。

原文： int result;

改为：int result = YAFFS_FAIL;

做了修改之后，覆盖掉linux-3.4.2/fs/yaffs2目录下的这两个源文件，再次make uImage，编译正常通过，之前的warning都不存在了。在开发板启动新的uImage，这时候已经能够正常挂接NAND Flash上的根文件系统了。Debug完成。