TW202422329A - 驅動包生成方法、驅動程式部署方法與相關設備 - Google Patents

Abstract

本申請公開了一種驅動包生成方法、驅動程式部署方法與相關設備，驅動包生成方法應用於第一電子設備，驅動包生成方法包括：獲取驅動程式源碼；根據驅動程式源碼配置規範檔；根據驅動程式源碼與規範檔生成第一格式之驅動包。驅動開發平臺系統獲取驅動程式源碼，根據驅動程式源碼配置規範檔後，根據驅動程式源碼與規範檔生成第一格式之驅動包，不同之目標系統均可從驅動開發平臺系統獲取第一格式之驅動包，並將第一格式的驅動包直接安裝到目標系統，進而完成驅動程式的部署，目標系統不需要再進行配置，使驅動程式之部署更加快速與便利。

Description

驅動包生成方法、驅動程式部署方法與相關設備

本申請涉及電腦技術領域，更具體而言，涉及一種驅動包生成方法、驅動程式部署方法、電子設備與電腦可讀存儲介質。

於Linux之開源策略下，各雲計算廠商通常會根據自身之需求，於標準版作業系統之基礎上定製作業系統，優化應用場景。定製化之作業系統之間存於差異，需要不同之驅動程式，才能驅動不同之定製化作業系統上之硬體設備正常工作。

對於定製化作業系統或非主流版本之作業系統而言，從硬體設備原廠官網上下載各類設備之驅動程式後，需要對驅動程式進行重新安裝、編譯與配置才能正常安裝並使用該驅動程式，從而完成該驅動程式於定製化之作業系統之部署，以使定製化之作業系統上之硬體設備正常運作。作業系統需要安裝於電子設備，使用者才能對作業系統進行相應之操作，需要花費大量之時間與成本，難以實現對驅動程式之靈活部署，浪費時間與成本。

鑒於以上內容本申請提供一種驅動包生成方法、驅動程式之部署方法與電子設備，本申請可使驅動程式之部署更加快速、靈活與便利。

本申請第一方面提供一種驅動包之生成方法，應用於第一電子設備，驅動包生成方法包括：

獲取驅動程式源碼；

根據所述驅動程式源碼配置規範檔；

根據所述驅動程式源碼與所述規範檔生成第一格式之驅動包。

本發明另一方面還提供一種無線通訊裝置，所述無線通訊裝置包括背蓋，所述無線通訊裝置還包括如上所述之天線系統。

如此，第一電子平臺之驅動開發平臺系統獲取驅動程式源碼，根據驅動程式源碼配置規範檔後，根據驅動程式源碼與規範檔生成第一格式之驅動包。不同之目標系統均可從驅動開發平臺系統獲取第一格式之驅動包，並藉由該第一格式之驅動包部署匹配本目標系統之驅動程式，目標系統不需要再進行配置，使驅動程式之部署更加快速、靈活與便利。

作為第一方面之一種可選之實施方式，根據所述驅動程式源碼配置規範檔包括：

根據所述驅動程式源碼生成設定檔與驅動程式檔，以完成所述規範檔之配置，其中，所述設定檔為系統自動載入指令之設定檔。

如此，根據驅動程式源碼生成設定檔與驅動程式檔，以完成規範檔之配置後，可使第一格式之驅動包具有用於系統自動載入指令之設定檔。於後續操作中，編譯成第二格式之驅動包安裝於目標系統後，響應於目標系統開啟後，目標系統能夠根據系統自動載入指令之設定檔實現驅動程式自動載入，驅動硬體設備正常工作。

作為第一方面之一種可選之實施方式，所述根據所述驅動程式源碼生成設定檔與驅動程式檔，以完成規範檔之配置包括：

將所述驅動程式檔存放於第一預設目錄之第一路徑，其中，所述第一路徑為系統內核之外置存儲路徑；

將所述設定檔存放於第二預設目錄之第二路徑，其中，所述第二路徑為所述規範檔之存儲路徑；

將所述第一路徑中之所述驅動程式檔與所述第二路徑中之所述設定檔集成至啟動列表，以完成所述規範檔之配置。

如此，驅動開發平臺系統將驅動程式檔與系統自動載入指令之設定檔與放於第一預設目錄中之第一路徑與第二預設目錄之第二路徑，集成至啟動清單，可使驅動程式檔結合設定檔，於啟動目標系統時，自動載入驅動程式。

作為第一方面之一種可選之實施方式，所述將所述第一路徑中之所述驅動程式檔與所述第二路徑中之所述設定檔集成至啟動列表之前，所述驅動包生成方法還包括：

重新生成內核之映射檔，以使所述設定檔生效；

如此，系統重新生成內核之映射檔，可使所述設定檔生效。

作為第一方面之一種可選之實施方式，所述驅動包生成方法還包括：

根據所述驅動程式源碼定義所述第一格式之驅動包之基本資訊，其中，基本資訊包括名稱、版本號、發行系列與授權方式。

如此，定義第一格式之驅動包之基本資訊可使後續生成之第二格式之驅動包符合目標系統環境，防止生成之第二格式之驅動包因不匹配目標系統環境而無法安裝。

作為第一方面之一種可選之實施方式，所述根據所述驅動程式源碼與所述規範檔生成第一格式之驅動包包括。

將所述驅動程式源碼存放於第三預設目錄，其中，所述第三預設目錄為所述驅動程式源碼之存儲路徑；

將配置之所述規範檔存放於第四預設目錄，其中，所述第四預設目錄為所述規範檔之存儲路徑；

根據所述第三預設目錄中之所述驅動程式源碼與所述第四預設目錄中之所述規範檔，生成所述第一格式之驅動包。

如此，將驅動程式源碼存放於第三預設目錄，並將規範檔存放於第四預設目錄，最後根據第三預設目錄中之驅動程式源碼與第四預設目錄中之規範檔，生成第一格式之驅動包。將已經配置好之規範檔與驅動程式源碼放置於指定之目錄下，方便後續找到配置好之規範檔，並生成第一格式之驅動包。

本申請第二方面提供一種驅動程式之部署方法，應用於第二電子設備，包括：

從第一電子設備獲取第一格式之驅動包；

安裝所述第一格式之驅動包；

將所述第一格式之驅動包編譯成第二格式之驅動包。

如此，第二電子設備平臺之目標系統獲取第一電子設備之驅動開發平臺系統之第一格式之驅動包，並安裝該驅動包，將第一格式之驅動包編譯成第二格式之驅動包後，目標系統響應於目標系統開啟指令，根據第二格式之驅動包載入驅動程式，根據驅動程式驅動硬體設備。分別於不同之目標操系統中編譯生成第二格式之驅動包。僅要一次於目標系統中編譯生成第二格式之驅動包，就可直接獲取該第二格式之驅動包安裝於多台與目標系統有相同作業系統之電子設備上，使多台電子設備均部署第二格式之驅動包，不需要再進行配置與編譯，可實現今多台電子設備中部署第二格式之驅動包時，部署靈活快速，省時省力。

作為第一方面之一種可選之實施方式，所述將所述第一格式之驅動包編譯成第二格式之驅動包之後包括：

將所述第二格式之驅動包發送給預設系統，以使所述預設系統安裝所述第二格式之驅動包。

如此，目標系統將生成之第二格式之驅動包發送給預設系統，預設系統接收第二格式之驅動包後安裝該第二格式之驅動包。僅要一次於目標系統中編譯生成第二格式之驅動包，就可直接獲取該第二格式之驅動包安裝於多台與目標系統有相同作業系統之電子設備上，使多台電子設備均部署第二格式之驅動包，不需要再進行配置與編譯，可實現今多台電子設備中部署第二格式之驅動包時，部署靈活快速，省時省力。

本申請第三方面提供一種電子設備，所述電子設備包括處理器與記憶體，所述記憶體中存儲有電腦程式，所述電腦程式被所述處理器執行時，實現上述項所述之生成方法或項所述之部署方法。

本申請第四方面提供一種電腦可讀存儲介質，其上存儲有電腦程式，所述電腦程式被處理器執行時，實現上述項所述之生成方法或項所述之部署方法。

本申請之驅動包生成方法、驅動程式之部署方法、電子設備與電腦可讀存儲介質，第一電子平臺之驅動開發平臺系統獲取驅動程式源碼，根據驅動程式源碼配置規範檔後，根據驅動程式源碼與規範檔生成第一格式之驅動包。不同之目標系統均可從驅動開發平臺系統獲取第一格式之驅動包，並藉由該第一格式之驅動包部署匹配本目標系統之驅動程式，目標系統不需要再進行配置，使驅動程式之部署更加快速、靈活與便利。

本申請之實施方式之附加方面與優點將於下面之描述中部分給出，部分將從下面之描述中變得明顯，或藉由本申請之實施方式之實踐瞭解到。

下面先對相關技術之情況做簡要說明。

於Linux之開源策略下，各雲計算廠商通常會根據自身之需求於標準版作業系統之基礎上定製作業系統，優化應用場景。定製化之作業系統之間存於差異，需要不同之驅動程式，才能驅動不同之定製化作業系統上之硬體設備正常工作。

硬體設備原廠官網通常僅針對標準系統，發行已完成編譯之驅動程式之相關檔，並且該驅動程式可直接安裝於標準化作業系統。對於定製化作業系統或非主流版本之作業系統而言，從硬體設備原廠官網上下載各類設備之驅動程式後，需要對驅動程式進行重新安裝與編譯，才能正常安裝並使用該驅動程式，從而完成該驅動程式於定製化之作業系統之部署，以使定製化之作業系統上之硬體設備正常運作。於重新編譯時，為相容定製化系統，可能要修改驅動程式之源碼。為滿足使用者需求，會為驅動程式之做一些配置，例如配置開機自動載入之設定檔，以使驅動程式於開機後自動運行。

同時，作業系統需要安裝於電子設備上，例如伺服器上，使用者才能對作業系統進行相應之操作。當伺服器之數量較多且伺服器之間之作業系統不一致時，需要發送不同之驅動程式之源碼到對應之作業系統之伺服器上重新安裝、編譯與進行一系列配置，以使驅動程式於開機後自動運行。該種情況下，需要花費大量之時間與成本，難以實現對驅動程式之靈活部署，浪費時間與成本。

本申請將驅動軟體安裝包簡稱為驅動包。

為此，本申請實施方式提供一種驅動包之生成方法、驅動程式之部署方法、電子設備與電腦可讀存儲介質使驅動程式之部署更加快速、靈活與便利。

請參閱圖1，圖1為驅動程式部署系統1000，是本申請之驅動程式之部署方法之某一應用場景圖。亦即說，本申請之驅動程式之部署方法可應用於圖1之驅動程式部署系統1000上。驅動程式部署系統1000包括第一電子設備100與第二電子設備200。第一電子設備100安裝有驅動開發平臺系統101，第二電子設備200安裝目標系統201，驅動開發平臺系統101與目標系統201之間可相互發送rpm格式驅動包與/或srpm格式驅動包。

驅動開發平臺系統101利用本申請之驅動包生成方法生成srpm格式驅動包後發送給目標系統201，目標系統201可安裝srpm格式驅動包後，編譯成匹配目標系統201環境之rpm格式驅動包。此時，使用者重啟第二電子設備200，第二電子設備200之目標系統201亦隨之啟動，響應於目標系統201之啟動指令，目標系統201根據rpm格式驅動包載入驅動程式，驅動程式驅動硬體設備工作。例如，回應於目標系統201之啟動指令，目標系統201根據rpm格式之顯示幕之驅動包，載入顯示幕之驅動程式，從而驅動顯示幕工作。

其中，電子設備可為伺服器。硬體設備可包括顯示器、輸入裝置、主機板、拓展卡、電源與中央處理器（central processing unit，CPU）等。

需要特別注意之是，驅動開發平臺系統101是指生成srpm格式驅動包之作業系統，目標系統201亦可為驅動開發平臺系統101。

為準確地對本申請中之技術內容進行敘述，以及為準確地理解本發明，於對具體實施方式進行說明之前先對本說明書中所使用之術語給出如下之解釋說明或定義。

驅動程式是電腦軟體術語，驅動程式全稱為“設備驅動程式”。驅動程式是一種可使電腦與硬體設備通訊之程式，相當於硬體設備之介面，作業系統藉由這個介面才能控制硬體設備之工作，例如，某一硬體設備未安裝驅動程式，作業系統無法識別到該設備，從而無法控制該設備進行相應之操作。可從硬體設備原廠官網上下載各類設備之驅動程式，下載之驅動程式可分為已經編譯完成之標準系統驅動與驅動程式源碼包。

源碼( Source Code )是指最原始程式之代碼。

Linux全稱GNU/Linux，是一種類UNIX作業系統，一個基於POSIX之多用戶、多工、支持多執行緒與多CPU之作業系統。

spec檔是規範檔，於Linux作業系統中用於指導rpmbuild命令構建srpm格式或rpm格式之驅動包。亦即是說，可先配置spec檔，然後作業系統根據spec檔，利用rpmbuild命令執行相應之操作，從而生成srpm格式或rpm格式之驅動包。

srpm格式驅動包裡之程式是未編譯而rpm格式驅動包裡之程式是已經編譯亦即是說，rpm格式驅動包是經過編譯之srpm格式驅動包，因此，srpm格式驅動包之代碼為源碼，而rpm格式驅動包裡之代碼不是源碼。

本申請之生成方法與部署方法可於Linux作業系統下實現。

請參閱圖2，圖2為本申請實施方式之驅動包生成方法之流程示意圖，本申請實施方式之驅動包之生成方法可應用於圖1之第一電子設備100，本申請實施方式之驅動包之生成方法可包括：

步驟S101：獲取驅動程式源碼。

驅動開發平臺系統101可到硬體設備原廠官網上下載各類硬體設備之驅動程式源碼壓縮包。

於一個示例中，第一電子設備100之驅動開發平臺系統101於輸入裝置之官網上，獲取輸入裝置之驅動程式源碼壓縮包。

步驟S102：根據驅動程式源碼配置規範檔；

規範檔是指spec檔，驅動開發平臺系統101獲取驅動程式源碼後，根據驅動程式源碼配置spec檔。驅動開發平臺系統101配置完spec檔後，於後續之操作中，會根據已經配置好之spec檔執行相應之動作，從而完成rpm格式驅動包或srpm格式驅動包於各階段之任務。

具體地，可分為三個部分配置spec檔，第一部分為驅動包之相關描述，第二部分為驅動包於各階段之操作，第三部分為驅動包之配置資訊。各階段可包括預編譯階段、編譯階段、安裝階段、清理階段、安裝前階段、安裝後階段、卸載前階段與卸載後階段。於預編譯階段，可執行解壓驅動程式源碼壓縮包與生成系統啟動，自動載入指令之設定檔之操作，例如生成depmod設定檔與darcut之設定檔。於編譯階段，可進行編譯srpm格式驅動包之操作。於安裝階段，可執行指定rpm格式驅動包中ko之檔、depmod之設定檔與dracut設定檔之安裝路徑之操作。於清理階段，可執行清理之多餘之中間檔之操作。於安裝後階段，可執行depmod與darcut命令，使depmod與darcut之設定檔生效之操作。於卸載後階段，可執行depmod與darcut命令，使depmod與darcut之設定檔失效之操作。其中，於完成編譯階段之前，可稱為srpm格式驅動包，完成編譯階段之後，可稱為rpm格式驅動包。例如，可按照以下代碼配置spec檔：

首先，配置第一部分關於驅動包之相關描述：

Summary: %{module} kernel module(s)    #驅動包相關描述；

Name: kmod-%{module}              #驅動包名稱；

Version: %{version}               #驅動主版本號；

Release: %{release}          #驅動發行序號；

License: GPLv2          #授權方式；

Source0: %{module}-%{version}-src.tar.gz     #驅動程式源碼壓縮包；

其中，%{module}、%{version}、%{kernel}是spec檔中之自訂之宏，通常於spec檔頭部定義。

其次，配置第二部分關於驅動包於各階段之操作：

%prep#預編譯階段；

echo override %{module} `uname -r | awk -F "-" '{print $1}'`-* weak-updates/%{module} ＞ $RPM_SOURCE_DIR/%{module}-depmod.conf；

#生成depmod設定檔；

echo add_drivers+=\" %{module} \" ＞；

$RPM_SOURCE_DIR/%{module}-dracut.conf；

#生成darcut設定檔；

%prep#預編譯階段；

echo override %{module} `uname -r | awk -F "-" '{print $1}'`-* weak-updates/%{module} ＞ $RPM_SOURCE_DIR/%{module}-depmod.conf；

#生成depmod設定檔；

echo add_drivers+=\" %{module} \" ＞；

$RPM_SOURCE_DIR/%{module}-dracut.conf；

#生成darcut設定檔；

%build    #編譯階段；

cd ./%{module}/#進入編譯目錄下；

./compile.sh#執行源碼包中之編譯腳本；

cp %{module}.ko $RPM_SOURCE_DIR/#拷貝編譯之驅動包；

%install#安裝階段；

install -m 644 -D $RPM_SOURCE_DIR/%{module}.ko；

$RPM_BUILD_ROOT/lib/modules/%-{kernel}/extra/%{module}/%{module}.ko#指定驅動包中KO檔之安裝路徑；

install -m 644 -D $RPM_SOURCE_DIR/%{module}-depmod.conf $RPM_BUILD_ROOT-/etc/depmod.d/%{module}.conf  #指定驅動包中depmod設定檔之安裝路徑；

install -m 644 -D $RPM_SOURCE_DIR/%{module}-dracut.conf $RPM_BUILD_ROOT-/etc/dracut.conf.d/%{module}.conf#指定驅動包中dracut設定檔之安裝路徑；

%clean#清理階段；

rm -rf $RPM_SOURCE_DIR/%{module}.ko $RPM_SOURCE_DIR/-%{module}-dracut.conf#清理產生之中間檔；

%post#安裝後階段；

depmod   #執行depmod與dracut命令使設定檔生效；

dracut –f；

其中，$RPM_SOURCE_DIR為RPM SPEC之全域變數，指/root/rpmbuild/SOURCES路徑。

最後，配置第三部分關於rpm格式之驅動包之配置資訊。配置資訊可包括待安裝檔列表與驅動包版本變更記錄。例如，可按照以下之配置方式配置關於rpm格式之驅動包之配置資訊。

%files#待安裝檔列表；

%defattr(644,root,root,755)          #設置內定檔案許可權；

/lib/modules/%{kernel}-/extra/%{module}/%{module}.ko；

/etc/depmod.d/%{module}.conf    ；

/etc/dracut.conf.d/%{module}.conf；

於一個示例中，驅動開發平臺系統101獲取驅動程式源碼後，根據之驅動程式源碼配置spec檔，具體地，從預編譯階段到完成編譯階段之前，配置如何生成srpm格式驅動包，完成編譯階段之後，配置如何生成rpm格式驅動包、如何將srpm格式驅動包編譯成rpm格式驅動包，以及如何安裝srpm格式驅動包與rpm格式驅動包等，從而完成對spec檔之配置。

步驟S103：根據驅動程式源碼與規範檔生成第一格式之驅動包。

第一格式之驅動包是指srpm格式驅動包。驅動開發平臺系統101根據驅動程式源碼與配置後之spec檔，可生產srpm格式驅動包。

可理解地，spec檔是規範檔，它說明瞭srpm格式與rpm格式驅動包如何被配置、安裝之哪些檔、安裝之目錄與於目標系統201上安裝時調用之系統級別活動等，從而定製化srpm格式之驅動包，當srpm格式之驅動包於目標系統201上安裝與編譯後，就可得到匹配目標系統201之定製化rpm格式之驅動包。

可理解地，驅動開發平臺系統101利用spec檔可定製srpm格式驅動包。該定製化srpm格式驅動包可安裝於不同目標系統201上進行編譯，從而生成可匹配不同作業系統之rpm格式驅動包，將該rpm格式驅動包安裝於多台電子設備上，多台電子設備與定製化作業系統相同之系統回應於電子設備系統開啟，能夠調用驅動程式驅動硬體設備正常工作，不需要再次進行驅動程式編譯與配置，該驅動包使驅動程式之部署更加快速、靈活與便利。

如此，驅動開發平臺系統101獲取驅動程式源碼，根據驅動程式源碼配置規範檔後，根據驅動程式源碼與規範檔生成第一格式之驅動包。不同之目標系統201均可從驅動開發平臺系統101獲取第一格式之驅動包，並藉由該第一格式之驅動包部署匹配本目標系統之驅動程式，目標系統201不需要再進行配置，使驅動程式之部署更加快速、靈活與便利。

作為一種可選之實施方式，步驟S102可包括：

步驟S201：根據驅動程式源碼生成設定檔與驅動程式檔，以完成規範檔之配置。

要實現開機自動載入驅動程式，需要執行相關指令，使啟動系統後自動載入驅動程式。例如，depmod與dracut指令，因此，用於系統自動載入之設定檔指該相關指令之設定檔，例如depmod之設定檔與dracut之設定檔。亦即說，設定檔為系統自動載入指令之設定檔。

因此，驅動開發平臺為使驅動程式於系統開啟後，能夠自動載入。於配置spec檔時，可於預編譯階段，配置生成系統自動載入之設定檔，從而使生成之srpm格式驅動包包括用於系統自動載入之設定檔。例如可按照以下之代碼配置：

%prep#預編譯階段；

echo override %{module} `uname -r | awk -F "-" '{print $1}'`-* weak-updates/%{module} ＞ $RPM_SOURCE_DIR/%{module}-depmod.conf；

#生成depmod設定檔；

於一個示例中，驅動開發平臺系統101於配置spec檔時，於預編譯階段，配置生成用於系統自動載入之設定檔，從而使生成之srpm格式驅動包包括用於系統自動載入之設定檔。當之srpm格式驅動包編譯成之rpm格式驅動包，並安裝於目標系統201後，回應於系統開啟後，目標系統201能夠根據設定檔實現驅動程式自動載入，驅動硬體設備正常工作。

同時，系統可配置於編譯階段，由驅動源碼編譯生成驅動程式檔，以便後續將設定檔與驅動程式檔集成至啟動清單中。

如此，根據驅動程式源碼生成設定檔與驅動程式檔，可完成規範檔之配置。

作為一種可選之實施方式，步驟S201可包括：

步驟S301：將驅動程式檔存放於第一預設目錄之第一路徑；

Linux作業系統內核有用於存放檔之目錄，分為內部存儲目錄與外置存儲目錄，內部存儲目錄映射有內部存儲路徑，外置存儲目錄映射有外置儲存路徑。內部存儲路徑佔用內核之體積，而外置存儲路徑不影響內核之體積。具體地，Linux作業系統將驅動內核模組存放於rpmbuild之工作目錄之BUILDROOT子目錄，具體為BUILDROOT路徑子目錄中存放之Linux作業系統內核之外置存儲路徑，該路徑是內核標準之驅動內核模組之外置路徑，例如路徑/lib/modules/%{kernel}/extra。亦即是說第一預設目錄為Linux作業系統內核之外置存儲目錄，第一路徑為Linux作業系統內核之外置存儲路徑。其中，驅動程式檔可以內核模組之形式存於，亦即是驅動程式檔可以.ko檔之形式存於。

可理解地，將驅動程式檔存放於Linux作業系統內核之外置存儲路徑，可儘量不影響Linux作業系統內核之體積。

步驟S302：將設定檔存放於第二預設目錄之第二路徑。

Linux作業系統將生成之用於開機自動加之載設定檔，存放於rpmbuild之工作目錄之BUILDROOT子目錄，具體為BUILDROOT子目錄中存放設定檔之儲存目錄，該儲存目錄有映射之存儲路徑，例如存儲路徑etc/depmod.d/%{module}.conf與存儲路徑/etc/dracut.conf.d。亦即是說，第二預設目錄是指設定檔之存儲目錄，第二路徑是指設定檔之存儲路徑。

步驟S303：將第一路徑中之驅動程式檔與第二路徑中之設定檔集成至啟動清單，以完成規範檔之配置。

可理解地，當啟動目標系統201時，目標系統201會自動載入啟動列表中之檔，因此，將用於系統開啟自動載入之設定檔與驅動程式檔集成至啟動清單，可使驅動程式檔結合設定檔，於啟動系統時，自動載入驅動程式。例如，驅動開放平臺可按照以下代碼配置spec檔。

%install#安裝階段；

install -m 644 -D $RPM_SOURCE_DIR/%{module}.ko；

$RPM_BUILD_ROOT/lib/modules/%-{kernel}/extra/%{module}/%{module}.ko#指定驅動包中KO檔之安裝路徑；

install -m 644 -D $RPM_SOURCE_DIR/%{module}-depmod.conf $RPM_BUILD_ROOT-/etc/depmod.d/%{module}.conf  #指定驅動包中depmod設定檔之安裝路徑；

install -m 644 -D $RPM_SOURCE_DIR/%{module}-dracut.conf $RPM_BUILD_ROOT-/etc/dracut.conf.d/%{module}.conf#指定驅動包中dracut設定檔之安裝路徑；

如此，驅動開發平臺系統101將驅動程式檔與系統自動載入指令之設定檔與驅動程式源碼放於第一預設目錄中之第一路徑與第二預設目錄之第二路徑，集成至啟動清單，可使驅動程式源碼結合設定檔，於啟動目標系統201時，自動載入驅動程式。

作為一種可選之實施方式，步驟S303可包括以下步驟：

步驟S401：重新生成內核之映射檔，以使設定檔生效；

具體地，Linux作業系統於完成RPM格式驅動包之安裝後，與卸載掉RPM格式驅動包後，亦即是於安裝後與卸載階段，可執行depmod與dracut命令，重新編譯該Linux作業系統之內核之initiramfs檔，使得用於開機自動載入設定檔於完成RPM格式驅動包之安裝後生效，與卸載掉RPM格式驅動包後失效。

因此，Linux作業系統於配置spec檔之安裝後與卸載階段時，可配置重新生成內核之映射檔之操作，映射檔指initramfs檔。

步驟S402：將第一路徑中之驅動程式檔與第二路徑中之設定檔集成至啟動列表。

Linux作業系統於配置spec檔時，可將用於開機自動載入之設定檔與驅動程式檔一起封裝成RPM格式驅動包。當RPM格式驅動包安裝於Linux作業系統上後，Linux作業系統根據用於開機自動載入之設定檔與驅動程式檔集成至啟動清單。

可理解地，當啟動Linux作業系統時，Linux作業系統會自動載入啟動清單中之檔，因此，將用於開機自動載入之設定檔與驅動程式檔集成至啟動清單。於啟動Linux作業系統時，會自動載入開機自動載入之設定檔與驅動程式檔，從而自動載入驅動程式。

例如，可按照以下之代碼配置：

%post#安裝後階段；

depmod   #執行depmod與dracut命令使設定檔生效；

dracut –f；

%postun #卸載後階段；

depmod   #執行depmod與dracut命令使設定檔失效；

dracut –f；

如此，系統重新生成內核之映射檔，以使所述設定檔生效，並將第一路徑中之驅動程式檔與第二路徑中之設定檔集成至啟動列表。於啟動系統時，系統載入啟動清單裡之檔，亦即是載入設定檔與驅動程式檔，從而使驅動程式自動載入。

作為一種可選之實施方式，驅動包生成方法還包括以下步驟：

S501：根據驅動程式源碼定義第一格式之驅動包之基本資訊。

驅動開發平臺系統101於生成設定檔之前，可先配置srpm格式之驅動包之基本資訊。基本資訊包括名稱、版本號、發行系列與授權方式。

亦即是說，配置第一部分關於驅動包之相關描述。相關描述可包括描述驅動包之內容概要，於配置時可使用標籤Summary；可包括驅動包之名稱，於配置時可使用標籤Name；可包括驅動程式之主版本號，於配置時可使用標籤Source；可包括驅動程式之發行系列號，於配置時可使用標籤Release；可包括驅動程式之授權方式，授權方式可使用GPLv2，於配置時可使用標籤License；包括使用之驅動程式源碼之源碼包，於配置時可使用標籤Source。例如，按照以下之代碼配置關於驅動包之相關描述：

Summary: %{module} kernel module(s)    #驅動包相關描述；

Name: kmod-%{module}              #驅動包名稱；

Version: %{version}               #驅動主版本號；

Release: %{release}          #驅動發行序號；

License: GPLv2          #授權方式；

Source0: %{module}-%{version}-src.tar.gz     #驅動程式源碼壓縮包。

可理解地，定義srpm格式驅動包之基本資訊可使後續生成之rpm格式驅動包符合目標系統201環境，防止生成之rpm格式驅動包因不匹配目標系統201環境而無法安裝。

如此，定義第一格式之驅動包之基本資訊可使後續生成之第二格式之驅動包符合目標系統201環境，防止生成之rpm格式驅動包因不匹配目標系統201環境而無法安裝。

作為一種可選之實施方式，步驟S103可包括以下步驟：

S601：將驅動程式源碼存放於第三預設目錄。

為構建srpm格式驅動包，需要準備打包環境，包括準備各種檔存放之工作目錄，驅動開發平臺系統101可藉由#rpmdev-setuptree命令來創建rpmbuild之工作目錄。後續藉由各種命令生成之各種檔可置於該目錄下。其中，rpmbuild之工作目錄包括用於存放spec檔之目錄，用代碼可表示為~/rpmbuild/SPECS/，包括用於存放源碼之目錄，用代碼可表示為~/rpmbuild/SOURCES/。包括用於存放srpm格式套裝軟體之目錄，用代碼可表示為~/rpmbuild/SRPMS/。

驅動開發平臺系統101配置完spec檔後，將已經配置完成之spec檔與驅動程式源碼分別放置於rpmbuild之工作目錄下，然後於spec檔放置之目錄下，執行rpmbuild命令，生成srpm格式驅動包，最後將srpm格式驅動包放置於rpmbuild之工作目錄下儲存。

驅動開發平臺系統101可將驅動程式源碼存放於源碼存儲目錄，亦即是說第三預設目錄是指源碼之存儲目錄，用代碼可表示為~/rpmbuild/SOURCES/。

S602：將規範檔存放於第四預設目錄。

驅動開發平臺系統101可將已經完成配置之spec檔存放規範檔之存儲目錄，亦即是說第四預設目錄為規範檔之存儲目錄，用代碼可表示為~/rpmbuild/SPECS。

S603：根據第三預設目錄中之驅動程式源碼與第四預設目錄中之規範檔，生成第一格式之驅動包。

於一個示例中，將spec檔放置於/root/rpmbuild/SPECS下，將驅動程式源碼放置於/root/rpmbuild/SOURCES/下，接著於/root/rpmbuild/SPECS下執行rpmbuild–bs ＜spec＞命令，生成srpm格式驅動包。

然後，可將生成之srpm格式驅動包放置/root/rpmbuild/SRPMS/並儲存。

可理解地，將已經編譯好之spec檔與驅動程式源碼放置於指定之目錄下，方便後續找到配置好之spec檔，並生成srpm格式驅動包。同時將生成之srpm格式驅動包放置於指定之目錄下，亦能夠方便後續找到生成之srpm格式驅動包。

如此，將驅動程式源碼存放於第三預設目錄，並將規範檔存放於第四預設目錄，最後根據第三預設目錄中之驅動程式源碼與第四預設目錄中之規範檔，生成第一格式之驅動包。將已經配置好之規範檔與驅動程式源碼放置於指定之目錄下，方便後續找到配置好之規範檔，並生成第一格式之驅動包。

本申請實施方式還提供一種驅動程式之部署方法，本申請之驅動程式之部署方法可應用於圖1之第二電子設備200上。

請參閱圖3，圖3為本申請之驅動程式之部署方法之流程示意圖，驅動程式之部署方法包括以下步驟：

S701：從第一電子設備獲取並安裝本申請生成方法所生成之第一格式之驅動包；

第二電子設備200之目標系統201從第一電子設備100之驅動開發平臺系統101獲取srpm格式驅動包。

S702：安裝第一格式之驅動包；

目標系統201獲取了srpm格式驅動包後，可執行rpm –ivh＜srpm＞命令，將srpm格式驅動包安裝到目標系統201中。

S703：將第一格式之驅動包編譯成第二格式之驅動包；

第二格式之驅動包是指rpm格式驅動包，rpm格式驅動包是經過編譯之srpm之驅動包，因此，rpm格式驅動包相比較srpm格式驅動包，rpm格式驅動裡之程式不是源碼。srpm格式驅動包裡之程式是源碼。

目標系統201將srpm格式驅動包安裝到目標系統201後，可執行rpm –bb ＜spec＞指令，將srpm格式驅動包編譯成rpm格式驅動包。

於一個示例中，第一電子設備100之驅動開發平臺系統101生成srpm格式驅動包後，將srpm格式驅動包發送到第二電子平臺之目標系統201下，目標系統201可執行rpm –ivh＜srpm＞命令，將srpm格式驅動包安裝到目標系統201中。接著，目標系統201跳轉至存放spec檔之目錄下，例如/root/rpmbuild/SPECS/下，執行rpm –bb ＜spec＞，完成驅動於該目標系統201之編譯，從而得到部署於該目標系統201上之rpm格式驅動包，於rpm格式驅動包之目錄下，如/root/rpmbuild/RPMS/目錄下，可找到生成之rpm格式驅動包。

於一個示例中，於第二電子設備200之目標系統201部署之rpm格式驅動包後。使用者重啟第二電子設備200，第二電子設備200之目標系統201亦隨之啟動，於目標系統201回應於目標系統201之開啟指令後，根據之rpm格式驅動包載入驅動程式，驅動硬體設備正常工作。

於一個應用場景中，以圖4之應用場景中示出之驅動程式部署系統1000為例進行說明，第一電子設備100上安裝有驅動開發平臺系統101，第三電子設備210上安裝有內核版本為1.0之目標系統211，第四電子設備220上安裝有內核版本2.0之目標系統212。

驅動開發平臺系統101生成srpm格式驅動包後，將srpm格式驅動包分別發送給內核版本為1.0之目標系統211與內核版本為2.0之目標系統212。

內核版本為1.0之目標系統211執行rpm –ivh＜srpm＞命令，將srpm格式驅動包安裝到內核版本為1.0之目標系統211中。跳轉至/root/rpmbuild/SPECS/，執行rpm –bb ＜spec＞，完成srpm格式驅動包於內核版本為1.0之目標系統211之編譯，得到部署於內核版本為1.0之目標系統211上之rpm格式驅動包，於/root/rpmbuild/RPMS/目錄下，可找到該rpm格式驅動包。該內核版本為1.0之目標系統211回應於系統開啟指令後，根據該rpm格式驅動包驅動第三電子設備210上之硬體設備正常工作。

同時，內核版本為2.0之目標系統212執行rpm –ivh＜srpm＞命令，將srpm格式驅動包安裝到內核版本為2.0之目標系統212中。跳轉至/root/rpmbuild/SPECS/，執行rpm–bb ＜spec＞，完成驅動於內核版本為2.0之目標系統212之編譯，得到部署於內核版本為2.0之目標系統212上之rpm格式驅動包，於/root/rpmbuild/RPMS/目錄下，可找到該rpm格式驅動包。該系統回應於系統開啟後，根據該rpm格式驅動包驅動第四電子設備220上之硬體設備正常工作。

可理解地，不同之目標系統201均可從驅動開發平臺系統101獲取srpm格式驅動包，並藉由該srpm格式驅動包部署匹配本目標系統之驅動程式，目標系統不需要再進行配置，使驅動程式之部署更加快速、靈活與便利。

如此，目標系統201獲取驅動開發平臺系統101之第一格式之驅動包，並安裝該驅動包，將第一格式之驅動包編譯成第二格式之驅動包後，目標系統201響應於目標系統201開啟指令，根據第二格式之驅動包驅動硬體設備工作。分別於不同之目標操系統中編譯生成第二格式之驅動包。可防止驅動開發平臺系統101與目標系統201不一致，導致無法安裝驅動包之現象。同時，僅要一次於目標系統201中編譯生成第二格式之驅動包，就可直接獲取該第二格式之驅動包安裝於多台與目標系統201有相同作業系統之電子設備上，使多台電子設備均部署第二格式之驅動包，可實現今多台電子設備中部署第二格式之驅動包時，部署靈活快速，省時省力。

作為一種可選之實施方式，步驟S704之後，驅動程式部署方法還可包括：

S801：第二格式之驅動包發送給預設系統，以使預設系統安裝第二格式之驅動包。

預設系統是指與目標系統相同之作業系統，例如，目標系統與預設系統均為內核版本為內核版本為1.0之作業系統。於一個應用場景中，以圖5之應用場景中示出之驅動程式部署系統1000為例進行說明，第一電子設備100上安裝有驅動開發平臺系統101，第三電子設備210與第五電子設備230上同樣安裝有內核版本為1.0之目標系統211。

驅動開發平臺系統101生成srpm格式驅動包後，發送給第三電子設備210之內核版本為1.0之目標系統211，內核版本為1.0之目標系統211執行rpm –ivh＜srpm＞命令，將srpm格式驅動包安裝到第三電子設備210中，執行rpm–bb ＜spec＞，完成驅動於內核版本為1.0之目標系統211之編譯，得到部署於內核版本為1.0之目標系統211上之rpm格式驅動包。

第五電子設備230獲取第三電子設備210生成之rpm格式驅動包，第五電子設備230之內核版本為1.0之目標系統211，執行rpm –ivh＜RPM＞命令後，部署了rpm格式驅動包。第五電子設備230之內核版本為1.0之目標系統211回應於系統開啟後，根據該rpm格式驅動包驅動第五電子設備230上之硬體設備正常工作。

可理解地，由於獲取之rpm格式驅動包是經過系統編譯該rpm格式驅動包匹配編譯系統之環境，因此該rpm格式驅動包可匹配與編譯系統相同環境之作業系統上。藉由srpm格式驅動包生成rpm格式驅動包，之後發送rpm格式驅動包至相同之目標系統201，相同之目標系統201不需要再重新編譯與配置，回應於系統開啟後，能夠根據rpm格式驅動包驅動電子設備上之硬體設備正常工作。

可理解地，僅要一次於目標系統201中編譯生成rpm格式之驅動包，就可直接發送該rpm格式之驅動包安裝於多台有相同目標系統201之電子設備上，使多台電子設備均部署驅動程式，可實現今多台電子設備中部署驅動程式時，部署靈活快速，省時省力。

如此，目標系統將生成之第二格式之驅動包發送給預設系統，預設系統接收第二格式之驅動包後安裝該第二格式之驅動包。僅要一次於目標系統中編譯生成第二格式之驅動包，就可直接獲取該第二格式之驅動包安裝於多台與目標系統有相同作業系統之電子設備上，使多台電子設備均部署第二格式之驅動包，不需要再進行配置與編譯，可實現今多台電子設備中部署第二格式之驅動包時，部署靈活快速，省時省力。

請參閱圖6所示，為本申請實施方式提供之電子設備10之一種結構示意圖。於一個實施方式中，電子設備10包括記憶體11及至少一個處理器12。本領域技術人員應該瞭解，圖6示出之電子設備10之結構並不構成本申請實施方式之限定，電子設備10還可包括比圖示更多或更少之其他硬體或者軟體，或者不同之部件佈置。

作為一種可選之實施方式，所述電子設備10包括一種能夠按照事先設定或存儲之指令，自動進行數值計算與/或資訊處理之終端，其硬體包括但不限於微處理器、專用積體電路、可程式設計閘陣列、數文書處理器及嵌入式設備等。作為一種可選之實施方式，記憶體11用於存儲程式碼與各種資料。所述記憶體11可包括唯讀記憶體（Read-Only Memory，ROM）、隨機記憶體（Random Access Memory，RAM）、可程式設計唯讀記憶體（Programmable Read-Only Memory，PROM）、可抹除可程式設計唯讀記憶體（Erasable Programmable Read-Only Memory，EPROM）、一次可程式設計唯讀記憶體（One-time Programmable Read-Only Memory，OTPROM）、電子抹除式可複寫唯讀記憶體（Electrically-Erasable Programmable Read-Only Memory，EEPROM）、唯讀光碟（Compact Disc Read-Only Memory，CD-ROM）或其他光碟記憶體、磁碟記憶體、磁帶記憶體、或者能夠用於攜帶或存儲資料之電腦可讀之任何其他介質。

作為一種可選之實施方式，所述至少一個處理器12可包括積體電路，例如可包括單個封裝之積體電路，亦可包括多個相同功能或不同功能封裝之積體電路，包括微處理器、數文書處理晶片、圖形處理器及各種控制晶片之組合等。所述至少一個處理器12是所述控制器之控制核心（Control Unit），藉由運行或執行存儲於所述記憶體11內之程式或者模組，以及調用存儲於所述記憶體11內之資料，以執行電子設備10之各種功能與處理資料。上述以軟體功能模組之形式實現之集成之單元，可存儲於一個電腦可讀取存儲介質中。上述軟體功能模組存儲於一個存儲介質中，包括複數指令用以使得一台電腦設備（可是個人電腦，終端，或者網路設備等）或處理器（processor）執行本申請各個實施方式所述方法之部分。所述記憶體11中存儲有程式碼，且所述至少一個處理器12可調用所述記憶體11中存儲之程式碼以執行相關之功能。於本申請之一個實施方式中，所述記憶體11存儲多個指令，所述多個指令被所述至少一個處理器12所執行以實現上述驅動包之生成方法與驅動程式之部署方法。具體地，所述至少一個處理器12對上述指令之具體實現方法對應實施方式中相關步驟之描述，於此不贅述。

本申請實施方式還提供了一種存儲介質。其中，所述存儲介質中存儲有電腦指令，所述指令於計算設備上運行時，使得所述計算設備可執行前述實施方式提供之驅動包之生成方法與驅動程式之部署方法。

本領域普通技術人員可意識到，結合本文中所公開之實施方式描述之各示例之單元及演算法步驟，能夠以電子硬體、或者電腦軟體與電子硬體之結合來實現。該等功能究竟以硬體還是軟體方式來執行，取決於技術方案之特定應用與設計約束條件。專業技術人員可對每個特定之應用以使用不同方法來實現所描述之功能，然該種實現不應認為超出本申請之範圍。所屬領域之技術人員可清楚地瞭解到，為描述之方便與簡潔，上述描述之系統、裝置與單元之具體工作過程，可參考前述方法實施方式中之對應過程，於此不再贅述。

於本申請所提供之幾個實施方式中，應該理解到，所揭露之系統、裝置與方法，可藉由其它之方式實現。例如，以上所描述之裝置實施方式僅僅是示意性例如，所述單元之劃分，僅僅為一種邏輯功能劃分，實際實現時可有另外之劃分方式，例如多個單元或元件可結合或者可集成到另一個系統，或一些特徵可忽略，或不執行。另一點，所顯示或討論之相互之間之耦合或直接耦合或通訊連接可是藉由一些介面，裝置或單元之間接耦合或通訊連接，可是電性，機械或其它之形式。所述作為分離部件說明之單元可是或者亦可不是物理上分開作為單元顯示之部件可是或者亦可不是物理單元，即可位元於一個地方，或者亦可分佈到多個網路單元上。可根據實際之需要選擇其中之部分或者全部單元來實現本實施方式方案之目的。另外，於本申請各個實施方式中之各功能單元可集成於一個處理單元中，亦可是各個單元單獨物理存於，亦可兩個或兩個以上單元集成於一個單元中注意，上述僅為本申請之較佳實施方式及所運用之技術原理。

本領域技術人員會理解，本申請不限於這裡項所述之特定實施方式，對本領域技術人員來說能夠進行各種明顯之變化、重新調整與替代而不會脫離本發明之保護範圍。因此，雖藉由以上實施方式對本申請進行了較為詳細之說明，然本發明不僅僅限於以上實施方式，於不脫離本發明之構思之情況下，還可包括更多其他等效實施方式，均屬於本發明之保護範疇。

1000:驅動程式部署系統 100:第一電子設備 101:驅動開發平臺系統 200:第二電子設備 201:目標系統 211:內核版本為1.0之目標系統 210:第三電子設備 212:內核版本為2.0之目標系統 220:第四電子設備 230:第五電子設備 S101-S103:步驟 S701-S703:步驟 10:電子設備 11:記憶體 12:處理器

圖1是本申請實施方式之驅動程式之部署方法之一場景示意圖；

圖2是本申請實施方式之驅動包之生成方法之流程示意圖；

圖3是本申請實施方式之驅動程式部署方法之流程示意圖；

圖4是本申請實施方式之驅動程式部署方法之一場景示意圖；

圖5是本申請實施方式之驅動程式部署方法之一場景示意圖；

圖6是本申請實施方式之電子設備之結構示意圖。

無

S101-S103:步驟

Claims (10)

1. 一種驅動包生成方法，應用於第一電子設備，其改良在於，所述驅動包生成方法包括： 獲取驅動程式源碼； 根據所述驅動程式源碼配置規範檔； 根據所述驅動程式源碼與所述規範檔生成第一格式之驅動包。
2. 如請求項1所述之驅動包生成方法，其中，所述根據所述驅動程式源碼配置規範檔包括： 根據所述驅動程式源碼生成設定檔與驅動程式檔，以完成所述規範檔之配置，其中，所述設定檔為系統自動載入指令之設定檔。
3. 如請求項2所述之驅動包生成方法，其中，所述根據所述驅動程式源碼生成設定檔與驅動程式檔，以完成所述規範檔之配置包括： 將所述驅動程式檔存放於第一預設目錄之第一路徑，其中，所述第一路徑為系統內核之外置存儲路徑； 將所述設定檔存放於第二預設目錄之第二路徑，其中，所述第二路徑為所述規範檔之存儲路徑； 將所述第一路徑中之所述驅動程式檔與所述第二路徑中之所述設定檔集成至啟動列表，以完成所述規範檔之配置。
4. 如請求項3所述之驅動包生成方法，其中，所述將所述第一路徑中之所述驅動程式檔與所述第二路徑中之所述設定檔集成至啟動列表之前，所述驅動包生成方法還包括： 重新生成內核之映射檔，以使所述設定檔生效。
5. 如請求項2所述之驅動包生成方法，其中，所述驅動包生成方法還包括： 根據所述驅動程式源碼定義所述第一格式之驅動包之基本資訊，其中，所述基本資訊包括名稱、版本號、發行系列與授權方式。
6. 如請求項1所述之驅動包生成方法，其中，所述根據所述驅動程式源碼與所述規範檔生成第一格式之驅動包，包括： 將所述驅動程式源碼存放於第三預設目錄，其中，所述第三預設目錄為所述驅動程式源碼之存儲路徑； 將配置之所述規範檔存放於第四預設目錄，其中，所述第四預設目錄為所述規範檔之存儲路徑； 根據所述第三預設目錄中之所述驅動程式源碼與所述第四預設目錄中之所述規範檔，生成所述第一格式之驅動包。
7. 一種驅動程式部署方法，應用於第二電子設備，其改良在於，所述驅動程式部署方法包括： 從第一電子設備獲取第一格式之驅動包； 安裝所述第一格式之驅動包； 將所述第一格式之驅動包編譯成第二格式之驅動包。
8. 如請求項7所述之部署方法，其中，所述將所述第一格式之驅動包編譯成第二格式之驅動包之後，所述驅動程式部署方法還包括： 將所述第二格式之驅動包發送給預設系統，以使所述預設系統安裝所述第二格式之驅動包。
9. 一種電子設備，其改良在於，所述電子設備包括處理器與記憶體，所述記憶體中存儲有電腦程式，所述電腦程式被所述處理器執行時，實現如請求項1至6中任一項所述之生成方法或如請求項7至8中任一項所述之部署方法。
10. 一種電腦可讀存儲介質，其上存儲有電腦程式，其改良在於，所述電腦程式被處理器執行時實現如請求項1至6中任一項所述之生成方法或如請求項7至8中任一項所述之部署方法。

Images