开发者社区> 问答> 正文

linux n内核驱动编译出错

我正在进行wifi驱动的移植,android SDK的版本是4.2.2 内核是3.2.0的,但是当我将驱动代码
加入到kernel里后,编译module时出现了如下错误:

CC [M] drivers/net/wireless/bcmdhd/wl_cfg80211.o
drivers/net/wireless/bcmdhd/wl_iw.c:3062:2: error: unknown field 'num_private' specified in initializer
drivers/net/wireless/bcmdhd/wl_iw.c:3062:17: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/net/wireless/bcmdhd/wl_iw.c:3062:17: warning: (near initialization for 'wl_iw_handler_def.get_wireless_stats') [enabled by default]
drivers/net/wireless/bcmdhd/wl_iw.c:3063:2: error: unknown field 'num_private_args' specified in initializer
drivers/net/wireless/bcmdhd/wl_iw.c:3063:22: warning: excess elements in struct initializer [enabled by default]
drivers/net/wireless/bcmdhd/wl_iw.c:3063:22: warning: (near initialization for 'wl_iw_handler_def') [enabled by default]
drivers/net/wireless/bcmdhd/wl_iw.c:3065:2: error: unknown field 'private' specified in initializer
drivers/net/wireless/bcmdhd/wl_iw.c:3065:2: warning: initialization makes integer from pointer without a cast [enabled by default]
drivers/net/wireless/bcmdhd/wl_iw.c:3065:2: warning: (near initialization for 'wl_iw_handler_def.num_standard') [enabled by default]
drivers/net/wireless/bcmdhd/wl_iw.c:3065:2: error: initializer element is not computable at load time
drivers/net/wireless/bcmdhd/wl_iw.c:3065:2: error: (near initialization for 'wl_iw_handler_def.num_standard')
drivers/net/wireless/bcmdhd/wl_iw.c:3066:2: error: unknown field 'private_args' specified in initializer
drivers/net/wireless/bcmdhd/wl_iw.c:3066:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/net/wireless/bcmdhd/wl_iw.c:3066:2: warning: (near initialization for 'wl_iw_handler_def.get_wireless_stats') [enabled by default]
make[4]: *** [drivers/net/wireless/bcmdhd/wl_iw.o] 错误 1
make[4]: *** 正在等待未完成的任务....
make[3]: *** [drivers/net/wireless/bcmdhd] 错误 2
make[2]: *** [drivers/net/wireless] 错误 2
make[1]: *** [drivers/net] 错误 2
make: *** [drivers] 错误 2
我找到了上面说的结构体如下:
struct iw_handler_def {
const iw_handler *standard;
__u16 num_standard;
#ifdef CONFIG_WEXT_PRIV
__u16 num_private;
__u16 num_private_args;
const iw_handler *private;
#endif
};

是不是因为kernel里面CONFIG_WEXT_PRIV没配置上啊,如果是的话要怎么配置啊,为什么我在内核里没找到这个选项啊, 而且我在.config文件中增加了CONFIG_WEXT_PRIV=y 再编译也还是出错,为什么啊?
哪位大神帮帮我啊,万分感谢

展开
收起
杨冬芳 2016-07-11 18:44:14 5123 0
1 条回答
写回答
取消 提交回答
  •  设置   1.安装kexec-tools工具,至于如何安装,在此不再多 说。   2.编译支持kdump的系统内核,我们叫他primary kernel。   确认以下内核选项已经被打开并重编内核。   1) 使能"kexec system call => Processor type and features." ,使内核支持kexec系统调用   CONFIG_KEXEC=y   2) 使能"Filesystem" => "Pseudo   filesystems."=> "sysfs file system support"   CONFIG_SYSFS=y   注意:如果"General Setup."=>"Configure standard kernel features (for small system)" 没有打开的话,"sysfs file system support"可能并不会在"Pseudo   filesystems."中出现,如果是 这种情况,可以直接检nfig文件,确认CONFIG_SYSFS是不是已经开启。   grep 'CONFIG_SYSFS'nfig   3)使能"Kernel hacking."=>"Compile the kernel with debug info" ,保证编译出的内核带有调试符号。因为dump分析工具在读取和分析dump文件时需要这些调试符号。   CONFIG_DEBUG_INFO=Y   3. 编译dump-capture kernel   针对不同的架构,内核选项也有不同,但是不论哪种架构,以下两个选项是必选的   "Processor type and features"=> "kernel crash dumps"   CONFIG_CRASH_DUMP=y   "Filesystems" => "Pseudo filesystems"=>"/proc/vmcore support"   CONFIG_PROC_VMCORE=y   (当 CONFIG_CRASH_DUMP 被选中时,CONFIG_PROC_VMCORE会被自动选中)   下面我们看一下针对不同的架构,编 译内核还有哪些特殊的选项   1)i386 和x86_64   *在i386上,使能高内存支持"Processor type and features"=>"high memory support"   CONFIG_HIGHMEM64G=y   or   CONFIG_HIGHMEM4G   * 在i386 和x86_64上,关闭"Processor type and features"=>"symmetric multi-processing support"   CONFIG_SMP=n   如果没有将该选项设为n,则需要在加载dump- capture kernel时指定参数maxcpus=1。   *如果想编译一个加载地址可浮动的内核,则选中"Processor type and features"=>"Build a relocatable kernel"   CONFIG_RELOCATABLE=y   * 设置合适的值给"Processor type and features"=>"Physical address where the kernel is loaded"   该值的设置与内核加载地址是否是可浮动的(即是否选中CONFIG_RELOCATABLE)有关。   如 果内核加载地址不可浮动, 则该值必须与crashkernel=Y@X中的X相同(至于crashkernel=Y@X的含义即如何使用将在后面讲到),例 如:crashkernel=64M@16M,则CONFIG_PHYSICAL_START=0x100000   0。   如果内核加载地址可 浮动,则CONFIG_PHYSICAL_START的值便可不必在意,使用默认的即可。不过为了保险起见,为了能使kdump正确执 行,CONFIG_PHYSICAL_START的值不论在何时,都要于X的值相同。   2)ppc64   除了前面两个必须的选项,其 余选项默认即可。   3)ia64   除了前面两个必须的选项,其余选项默认即可。   4.准备好两个内核后,即可按如下步 骤使用kdump   1)使用primary kernel启动系统,但是要在启动参数中加入“crashkernel=Y@X”,Y表示为dump-capture kernel 预留了多少内存空间,X该段空间的起始地址,即内核选项中CONFIG_PHYSICAL_START的值。   对于x86和x86_64架构,一般 使用crashkernel=64M@16M,CONFIG_PHYSICAL_START=0x1000000   对于ppc64架构,一般使用 crashkernel=128M@32M,CONFIG_PHYSICAL_START=0x2000000   对于ia64架构,通常使用 crashkernel=256M@256M。   2)加载dump-capture kernel   系统启动后,即可加载dump- capture kernle。   不同的架构,可以选择使用为压缩的dump-capture kernle (vmlinux) 或者压缩过的dump-capture kernle(bzImage/vmlinuz)。   i386 和x86_64:   如果dump-capture kernel编译时未选中CONFIG_RELOCATABLE,则只能使用vmlinux   如果dump-capture kernel编译时打开了CONFIG_RELOCATABLE,则可以使用bzImage/vmlinuz   ppc64 :   只能使用vmlinux   ia64:   可以使用vmlinux或者vmlinuz.gz   加载方法:   kexec -p <dump-capture-kernel-vmlinux-image> \   --initrd=<initrd-for-dump-capture-kernel> --args-linux \   --append="root=<root-dev> <arch-specific-options>"   dump- capture-kernel-vmlinux-image:表示存放dump-capture kernel 的路径   initrd-for- dump-capture-kernel:表示initrd的路径,如果没有,可以省略该参数   --args-linux:表示Pass linux kernel style options,没看明白什么意思,但是ia64架构不需要加这个参数,其他架构都要有。   --append: 该参数后跟内核启动参数。   arch-specific-options:内核启动参数的一部分,该处根据不同架构,填写不同参数。 i386, x86_64 和 ia64 填"1 irqpoll maxcpus=1 reset_devices",ppc64填"1 maxcpus=1 noirqdistrib reset_devices"。   注:   默认情况下,ELF文件头采用ELF64格式存储以支持那些拥有超过 4GB内存的系统。但是可以指定“--elf32-core-headers”标志以 强制使用ELF32格式的ELF文件头。这个标志是有必要注意的,一个重要的原因就是:当前版本的GDB不能在一个32位系统上打开一个使用ELF64格 式的vmcore文件。ELF32格式的文件头不能使用在一个“没有物理地址扩展”(non-PAE)的系统上。(即是说,少于4GB内存的系统)   1 这个参数,将启动“转储捕捉内核”到一个没有网络支持的单用户模式。如果你希望有网络支持,那么使用“init 3”   maxcpus=1,这个前 面说过,如果CONFIG_SMP=n,则需要在启动参数中加入maxcpus=1。   irqpoll 的启动参数可以减低由于在“转储捕获内核”中使用了“共享中断”技术而导致出现驱动初始化失败这种情况发生的概率。   举例:   kexec -p /boot/vmlinux_capture --args-linux --append="root=/dev/nfs rw nfsroot=128.224.149.6:/tftpboot/cxu/15554/rootfs ip=dhcp console=ttyS0,115200 1 maxcpus=1 noirqdistrib reset_devices"   3)测试 kdump是否成功   手动产生一个crash:echo c > /proc/sysrq-trigger。   或者可以些一个强制产生 crash的模块。   如果成功,系统将会进入热启动过程,系统启动完成后,可以执行一下uname -a ,看看内核的名字是不是有-kdump的标签呢?   然后就可以把生成的转储文件vmcore拷贝出来了,直接cp即可:   cp /proc/vmcore <anywhere>   也可以通过/dev/oldmem这个设备将其考出:   cd ~   mknod /dev/oldmem c 1 12   dd if=/dev/oldmem of=oldmem.001   成功将vmcore 拷贝出来后即可重启系统了。   4)分析vmcore文件   在开始分析“转储文件”之前,应该确定重启到一个稳定的内核。   可以 使用GDB在‘转储文件’上做有限的分析。分析的时候需要“带有调试信息的vmlinux文件”(编译的时候带有-g选项),运行如下命令:   gdb vmlinux vmcore   注意:GDB不能分析x86平台上以ELF64格式产生的“内核转储文件”。在一个最大内存为4GB的系统上,可 以通过在“转储捕捉内核”上指定“--elf32-core-headers”标志来使用ELF32格式的文件头。   也可以使用Crash工具集来 分析Kdump产生的“内核转储文件”,crash 工具可以到网上下载:   ~anderson/   以上文档主要是翻译自内核自带文档linux/Documentation/kdump/kdump.txt,部分使用自己的语言表达。如有错误,请指正。 标签: 内核崩溃转储机制 Linux
    

    “答案来源于网络,供您参考”

    2019-09-24 17:44:09
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
Alibaba Cloud Linux 3 发布 立即下载
ECS系统指南之Linux系统诊断 立即下载
ECS运维指南 之 Linux系统诊断 立即下载