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了