Lichee （六）配置核心時的一點小優化

我們在分析《

lichee（二）在sun4i_crane平台下的編譯

》的時候，居然沒有乙個步驟是在配置核心

make arch=arm menuconfig

仔細的讀過的**的會發現，在build_kernel有這麼一段話

if [ ! -e .config ]; then

echo -e "\n\t\tusing default config... ...!\n"

cp arch/arm/configs/sun4i_crane_defconfig .config

作用是，當不存在.config時，就將arch/arm/configs/sun4i_crane_defconfig拷貝到.config，這樣我們就不需要在編譯kernel的時候去執行make menuconfig來配置核心了。可是我們在實際移植驅動的過程中，往往需要修改.config。這時就不得不面臨乙個問題了，究竟什麼時候不存在.config檔案呢，當然是我們第一次從git 轉殖下來**的時候。隨之就有乙個新的問題，當我們想給我們專案內部的人共享**的時候，他編譯的核心並不是我們這邊配置好的.config檔案，而是arch/arm/configs/sun4i_crane_defconfig，這樣很有可能導致你和你的夥伴編譯的並不是同一套配置產生的kernel；還有另外乙個問題，比如我們有2個產品，方案基本相同，只是幾個外設不同，我們又覺得弄多套**維護起來過於麻煩，就這種需求來說，我們有一種最簡單的解決方案，我們在核心目錄arch/arm/configs/下，也建立乙個新的defconfig檔案，根據前面幾篇文章對於目標產品的命名，我們就叫mt7332_defconfig。

我們分析了這麼多關於lichee bsp自動化的過程，這些內容全部都是人家的，這次我們檢驗一下我們學習成果，弄一點咱們自己的東西。

就像我們在《

lichee（二）在sun4i_crane平台下的編譯》中的分析，lichee中的build.sh直接指向了buildroot/scripts/common.sh，之前我們一直沒有分析下面的**段

while getopts hp:m:k: option

docase $option in

h) show_help

exit 0

;;p) platform=$optarg

;;m) module=$optarg

;; k) kern_ver=$optarg

update_kdir $kern_ver

;;*) show_help

exit 1

;;esac

done

很明顯這段**是在接收指令碼的引數，還記不記得我們編譯的命令 ./build.sh -p sun4i_crane -k 3.0 這裡我們新加乙個引數 -v 意思就是verndor

改動後如下：

vendor=""

..................

while getopts hp:m:k:v: option do

case $option in

h) show_help

exit 0 ;;

p) platform=$optarg ;;

m) module=$optarg ;;

v) vendor=$optarg

;; k) kern_ver=$optarg

update_kdir $kern_ver ;;

*) show_help

exit 1 ;;

esac

done

這裡我們的-v傳進來的值只是在lichee目錄下的build.sh, 經過《

lichee（二）在sun4i_crane平台下的編譯

》的分析，我們需要將vendor的值傳入到lichee/linux-3.0/目錄下的build.sh

同樣地，在linux-3.0目錄下也要新增-v引數

while getopts hp:m:v: option
do case $option in
h) show_help
;; p) platform=$optarg
;; m) module=$optarg
;; v) vendor=$optarg
;; *) show_help
;;esac
done

這裡我們就要對vendor的值進行判斷了(假設我們還有一款產品叫mt7***)

if [ "$vendor" = mt7332 ]; then
make arch=arm mt7332_defconfig
elif [ "$vendor" = mt7*** ]; then
make arch=arm mt7***_defconfig
else
echo "use current .config $vendor"
fi

當我們-v傳進來的是mt7332的話，我們就用mt7332_defconfig這個配置，如果是mt7***的話，就用mt7***_defconfig，以此類推。如果不帶-v引數，就代表用的是當前的.config檔案

這段指令碼一定要放在實際編譯之前，也就是要放在下面這段**之前

if [ -x ./scripts/build_$.sh ]; then ./scripts/build_$.sh $module else printf "\nerror: invalid platform\n" show_help exit 1

fi

如何建立mt7332_defconfig？這個問題其實也很簡單，當我們在sun4i_crane_defconfig的基礎上進行make menuconfig結束的時候，將產生的.config檔案拷貝到arch/arm/configs/目錄下

假設，我們的mt7332產品，剛剛換了一款3g模，例項如下

# 配置自己的新增的驅動模組

make arch=arm menuconfig

#將配置好的.config檔案拷貝到mt7332_defconfig

cp .config arch/arm/configs/mt7332_defconfig

# 回到lichee目錄

cd ..

#編譯./build.sh -p sun4i_crane -k 3.0 -v mt7332

至此，我們就可以在同一套核心**中，維護多款目標產品了

Lichee （六）配置核心時的一點小優化

Lichee （六）優化配置的微核心

vsftp一點配置

程式設計時的一點小知識

Lichee （六） 配置核心時的一點小優化

Lichee （六） 優化配置的微核心

vsftp一點配置

程式設計時的一點小知識

相關推薦

Lichee （六）配置核心時的一點小優化

Lichee （六）優化配置的微核心