1. linux 内核裁剪 + linux驱动，一般需要多少时间
内核裁剪熟悉了十几分钟搞定，要是不熟悉，就要很久了，因为内核也分目录的，每目录下的每项都要明白是干什么的才能取舍。驱动一般包含在内核内，linux系统通过内核管理设备，外部安装的较少。
我常用menuconfig来编译内核。在gentoo系统下有genkernel软件，更方便一些。当然，gentoo系统安装起来不方便。
2. 有c、c++语言基础学习linux驱动需要多长时间
应该很快，主要是你会操作硬件读写就好办。
内核编程主要还是基于 C 而不是 C++ 的编程，相对容易很多。
3. arm linux驱动开发多长时间能拿得出手
不是时间的问题，只要你有过比较突出的经历，一个月也不算短；如果你整天混日子，没有拿得出手的业绩，那自然就那不出手了
4. linux内核驱动占用时间多久会导致内核崩溃
设置
1.安装kexec-tools工具，至于如何安装，在此不再多 说。
2.编译支持kmp的系统内核，我们叫他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" ，保证编译出的内核带有调试符号。因为mp分析工具在读取和分析mp文件时需要这些调试符号。
CONFIG_DEBUG_INFO=Y
3. 编译mp-capture kernel
针对不同的架构，内核选项也有不同，但是不论哪种架构，以下两个选项是必选的
"Processor type and features"=> "kernel crash mps"
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，则需要在加载mp- 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的值便可不必在意，使用默认的即可。不过为了保险起见，为了能使kmp正确执 行，CONFIG_PHYSICAL_START的值不论在何时，都要于X的值相同。
2）ppc64
除了前面两个必须的选项，其 余选项默认即可。
3）ia64
除了前面两个必须的选项，其余选项默认即可。
4.准备好两个内核后，即可按如下步 骤使用kmp
1）使用primary kernel启动系统，但是要在启动参数中加入“crashkernel=Y@X”，Y表示为mp-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）加载mp-capture kernel
系统启动后，即可加载mp- capture kernle。
不同的架构，可以选择使用为压缩的mp-capture kernle （vmlinux） 或者压缩过的mp-capture kernle（bzImage/vmlinuz）。
i386 和x86_64：
如果mp-capture kernel编译时未选中CONFIG_RELOCATABLE，则只能使用vmlinux
如果mp-capture kernel编译时打开了CONFIG_RELOCATABLE，则可以使用bzImage/vmlinuz
ppc64 :
只能使用vmlinux
ia64：
可以使用vmlinux或者vmlinuz.gz
加载方法：
kexec -p <mp-capture-kernel-vmlinux-image> \
--initrd=<initrd-for-mp-capture-kernel> --args-linux \
--append="root=<root-dev> <arch-specific-options>"
mp- capture-kernel-vmlinux-image：表示存放mp-capture kernel 的路径
initrd-for- mp-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）测试 kmp是否成功
手动产生一个crash：echo c > /proc/sysrq-trigger。
或者可以些一个强制产生 crash的模块。
如果成功，系统将会进入热启动过程，系统启动完成后，可以执行一下uname -a ,看看内核的名字是不是有-kmp的标签呢？
然后就可以把生成的转储文件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工具集来 分析Kmp产生的“内核转储文件”,crash 工具可以到网上下载：
~anderson/
以上文档主要是翻译自内核自带文档linux/Documentation/kmp/kmp.txt，部分使用自己的语言表达。如有错误，请指正。
标签： 内核崩溃转储机制 Linux
5. linux驱动 执行 make moles是不是把所有的驱动都编译了，好长时间都没编译完啊
make moles 是编译所有的模块驱动
即，在make menuconfig 配置中选M的选项，一般不会很长时间。你可以看看打印出的log，另外你是不是编译你自己的模块，有可能是你的makefile循环编译了。
6. linuxn内核驱动延时怎么做
jiffies
计数器定时器中断由系统定时硬件以规律地间隔产生; 这个间隔在启动时由内核根据 HZ 值来编程, HZ 是一个体系依赖的值, 每次发生一个时钟中断, 一个内核计数器的值递增.这个计数器在系统启动时初始化为 0, 因此它代表从最后一次启动以来的时钟嘀哒的数目.
这个计数器和来读取它的实用函数位于 , 尽管你会常常只是包含 ,
#includeunsigned long j, stamp_1, stamp_half, stamp_n; j = jiffies; /* read the current value */stamp_1 = j + HZ; /* 1 second in the future */stamp_half = j + HZ/2; /* half a second */stamp_n = j + n * HZ / 1000; /* n milliseconds */
忙等待
如果你想延时执行多个时钟嘀哒, 允许在值中某些疏忽, 最容易的( 尽管不推荐 ) 的实现是一个监视 jiffy 计数器的循环. 这种忙等待实现常常看来象下面的代码, 这里j1 是 jiffies 的在延时超时的值:
while (time_before(jiffies, j1)){}
超时 到目前为止所展示的次优化的延时循环通过查看 jiffy 计数器而不告诉任何人来工作. 但是最好的实现一个延时的方法, 如你可能猜想的, 常常是请求内核为你做.有 2 种方法来建立一个基于 jiffy 的超时, 依赖于是否你的驱动在等待其他的事件.
如果你的驱动使用一个等待队列来等待某些其他事件, 但是你也想确保它在一个确定时间段内运行, 可以使用 wait_event_timeout 或者wait_event_interruptible_timeout:
#includelong wait_event_timeout(wait_queue_head_t q, condition, long timeout);long wait_event_interruptible_timeout(wait_queue_head_t q, condition, long timeout);
这些函数在给定队列上睡眠, 但是它们在超时(以 jiffies 表示)到后返回. 因此, 它们实现一个限定的睡眠不会一直睡下去. 注意超时值表示要等待的 jiffies 数, 不是一个绝对时间值. 这个值由一个有符号的数表示, 因为它有时是一个相减运算的结果, 尽管这些函数如果提供的超时值是负值通过一个 printk 语句抱怨. 如果超时到, 这些函数返回 0; 如果这个进程被其他事件唤醒, 它返回以 jiffies 表示的剩余超时值. 返回值从不会是负值, 甚至如果延时由于系统负载而比期望的值大.
wait_event_timeout 和 wait_event_interruptible_timeout 被设计为有硬件驱动存在, 这里可以用任何一种方法来恢复执行: 或者有人调用 wake_up 在等待队列上, 或者超时到. 这不适用于 jitqueue, 因为没人在等待队列上调用 wake_up ( 毕竟, 没有其他代码知道它 ), 因此这个进程当超时到时一直唤醒. 为适应这个特别的情况, 这里你想延后执行不等待特定事件, 内核提供了 schele_timeout 函数, 因此你可以避免声明和使用一个多余的等待队列头:
#includesigned long schele_timeout(signed long timeout);
这里, timeout 是要延时的 jiffies 数. 返回值是 0 除非这个函数在给定的 timeout 流失前返回(响应一个信号). schele_timeout 请求调用者首先设置当前的进程状态, 因此一个典型调用看来如此:
set_current_state(TASK_INTERRUPTIBLE);schele_timeout (delay);
第一行调用 set_current_state 来设定一些东西以便调度器不会再次运行当前进程, 直到超时将它置回 TASK_RUNNING 状态. 为获得一个不可中断的延时, 使用TASK_UNINTERRUPTIBLE 代替.
短延时
当一个设备驱动需要处理它的硬件的反应时间, 涉及到的延时常常是最多几个毫秒.
内核函数 ndelay, udelay, 以及 mdelay 对于短延时好用, 分别延后执行指定的纳秒数, 微秒数或者毫秒数. 它们的原型是:
#includevoid ndelay(unsigned long nsecs);void udelay(unsigned long usecs);void mdelay(unsigned long msecs);
有另一个方法获得毫秒(和更长)延时而不用涉及到忙等待. 文件 声明这些函数:
void msleep(unsigned int millisecs);unsigned long msleep_interruptible(unsigned int millisecs);void ssleep(unsigned int seconds)
前 2 个函数使调用进程进入睡眠给定的毫秒数. 一个对 msleep 的调用是不可中断的; 你能确保进程睡眠至少给定的毫秒数. 如果你的驱动位于一个等待队列并且你想唤醒来打断睡眠, 使用 msleep_interruptible. 从 msleep_interruptible 的返回值正常地是 0; 如果, 但是, 这个进程被提早唤醒, 返回值是在初始请求睡眠周期中剩余的毫秒数. 对 ssleep 的调用使进程进入一个不可中断的睡眠给定的秒数.
7. linux 5.0 网卡是realtek8111的网卡，请问怎样安装驱动呀弄了老长时间了，也没有弄好。郁闷。
其实内核中包含该网卡的驱动
下载内核源代码 保存到/usr/src
解压 tar jxvf *.tar.bz2
ln -s /usr/src/linux-2.6.xx /usr/src/linux
cd linux
make mrproper
make menuconfig
这时候选中
Device Drivers
[*] Network device support --->
[*] Ethernet (1000 Mbit) --->
<M> Realtek 8169 gigabit ethernet support
保存退出
make && make moles_install
运行depmod
重启 就ok了