linux內核除法

❶ 如何參與linux 內核開發

如何參與Linux內核開發
---------------------

這是一篇將如何參與Linux內核開發的相關問題一網打盡的終極秘笈。它將指導你
成為一名Linux內核開發者，並且學會如何同Linux內核開發社區合作。它盡可能不
包括任何關於內核編程的技術細節，但會給你指引一條獲得這些知識的正確途徑。

如果這篇文章中的任何內容不再適用，請給文末列出的文件維護者發送補丁。

入門
----

你想了解如何成為一名Linux內核開發者？或者老闆吩咐你「給這個設備寫個Linux
驅動程序」？這篇文章的目的就是教會你達成這些目標的全部訣竅，它將描述你需
要經過的流程以及給出如何同內核社區合作的一些提示。它還將試圖解釋內核社區
為何這樣運作。

Linux內核大部分是由C語言寫成的，一些體系結構相關的代碼用到了匯編語言。要
參與內核開發，你必須精通C語言。除非你想為某個架構開發底層代碼，否則你並
不需要了解（任何體系結構的）匯編語言。下面列舉的書籍雖然不能替代扎實的C
語言教育和多年的開發經驗，但如果需要的話，做為參考還是不錯的：
- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
《C程序設計語言（第2版·新版）》（徐寶文 李志 譯）[機械工業出版社]
- "Practical C Programming" by Steve Oualline [O'Reilly]
《實用C語言編程（第三版）》（郭大海 譯）[中國電力出版社]
- "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
《C語言參考手冊（原書第5版）》（邱仲潘 等譯）[機械工業出版社]

Linux內核使用GNU C和GNU工具鏈開發。雖然它遵循ISO C89標准，但也用到了一些
標准中沒有定義的擴展。內核是自給自足的C環境，不依賴於標准C庫的支持，所以
並不支持C標准中的部分定義。比如long long類型的大數除法和浮點運算就不允許
使用。有時候確實很難弄清楚內核對工具鏈的要求和它所使用的擴展，不幸的是目
前還沒有明確的參考資料可以解釋它們。請查閱gcc信息頁（使用「info gcc」命令
顯示）獲得一些這方面信息。

請記住你是在學習怎麼和已經存在的開發社區打交道。它由一群形形色色的人組成，
他們對代碼、風格和過程有著很高的標准。這些標準是在長期實踐中總結出來的，
適應於地理上分散的大型開發團隊。它們已經被很好得整理成檔，建議你在開發
之前盡可能多的學習這些標准，而不要期望別人來適應你或者你公司的行為方式。

法律問題
--------

Linux內核源代碼都是在GPL（通用公共許可證）的保護下發布的。要了解這種許可
的細節請查看源代碼主目錄下的COPYING文件。如果你對它還有更深入問題請聯系
律師，而不要在Linux內核郵件組上提問。因為郵件組里的人並不是律師，不要期
望他們的話有法律效力。

對於GPL的常見問題和解答，請訪問以下鏈接：
http://www.gnu.org/licenses/gpl-faq.html

文檔
----

Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與內核社區互動有著
不可估量的價值。當一個新的功能被加入內核，最好把解釋如何使用這個功能的文
檔也放進內核。當內核的改動導致面向用戶空間的介面發生變化時，最好將相關信
息或手冊頁(manpages)的補丁發到[email protected]，以向手冊頁(manpages)
的維護者解釋這些變化。

以下是內核代碼中需要閱讀的文檔：
README
文件簡要介紹了Linux內核的背景，並且描述了如何配置和編譯內核。內核的
新用戶應該從這里開始。

Documentation/Changes
文件給出了用來編譯和使用內核所需要的最小軟體包列表。

Documentation/CodingStyle
描述Linux內核的代碼風格和理由。所有新代碼需要遵守這篇文檔中定義的規
范。大多數維護者只會接收符合規定的補丁，很多人也只會幫忙檢查符合風格
的代碼。

Documentation/SubmittingPatches
Documentation/SubmittingDrivers
這兩份文檔明確描述如何創建和發送補丁，其中包括（但不僅限於)：
- 郵件內容
- 郵件格式
- 選擇收件人
遵守這些規定並不能保證提交成功（因為所有補丁需要通過嚴格的內容和風格
審查），但是忽視他們幾乎就意味著失敗。

其他關於如何正確地生成補丁的優秀文檔包括：
"The Perfect Patch"
http://userweb.kernel.org/~akpm/stuff/tpp.txt
"Linux kernel patch submission format"
http://linux.yyz.us/patch-format.html

Documentation/stable_api_nonsense.txt
論證內核為什麼特意不包括穩定的內核內部API，也就是說不包括像這樣的特
性：
- 子系統中間層（為了兼容性？）
- 在不同操作系統間易於移植的驅動程序
- 減緩（甚至阻止）內核代碼的快速變化
這篇文檔對於理解Linux的開發哲學至關重要。對於將開發平台從其他操作系
統轉移到Linux的人來說也很重要。

Documentation/SecurityBugs
如果你認為自己發現了Linux內核的安全性問題，請根據這篇文檔中的步驟來
提醒其他內核開發者並幫助解決這個問題。

Documentation/ManagementStyle
描述內核維護者的工作方法及其共有特點。這對於剛剛接觸內核開發（或者對
它感到好奇）的人來說很重要，因為它解釋了很多對於內核維護者獨特行為的
普遍誤解與迷惑。

Documentation/stable_kernel_rules.txt
解釋了穩定版內核發布的規則，以及如何將改動放入這些版本的步驟。

Documentation/kernel-docs.txt
有助於內核開發的外部文檔列表。如果你在內核自帶的文檔中沒有找到你想找
的內容，可以查看這些文檔。

Documentation/applying-patches.txt
關於補丁是什麼以及如何將它打在不同內核開發分支上的好介紹

內核還擁有大量從代碼自動生成的文檔。它包含內核內部API的全面介紹以及如何
妥善處理加鎖的規則。生成的文檔會放在 Documentation/DocBook/目錄下。在內
核源碼的主目錄中使用以下不同命令將會分別生成pdf、Postscript、HTML和手冊
頁等不同格式的文檔：
make pdfdocs
make psdocs
make htmldocs
make mandocs

如何成為內核開發者
------------------
如果你對Linux內核開發一無所知，你應該訪問「Linux內核新手」計劃：
http://kernelnewbies.org
它擁有一個可以問各種最基本的內核開發問題的郵件列表（在提問之前一定要記得
查找已往的郵件，確認是否有人已經回答過相同的問題）。它還擁有一個可以獲得
實時反饋的IRC聊天頻道，以及大量對於學習Linux內核開發相當有幫助的文檔。

網站簡要介紹了源代碼組織結構、子系統劃分以及目前正在進行的項目（包括內核
中的和單獨維護的）。它還提供了一些基本的幫助信息，比如如何編譯內核和打補
丁。

如果你想加入內核開發社區並協助完成一些任務，卻找不到從哪裡開始，可以訪問
「Linux內核房管員」計劃：
http://kernelnewbies.org/KernelJanitors
這是極佳的起點。它提供一個相對簡單的任務列表，列出內核代碼中需要被重新
整理或者改正的地方。通過和負責這個計劃的開發者們一同工作，你會學到將補丁
集成進內核的基本原理。如果還沒有決定下一步要做什麼的話，你還可能會得到方
向性的指點。

如果你已經有一些現成的代碼想要放到內核中，但是需要一些幫助來使它們擁有正
確的格式。請訪問「內核導師」計劃。這個計劃就是用來幫助你完成這個目標的。它
是一個郵件列表，地址如下：
http://selenic.com/mailman/listinfo/kernel-mentors

在真正動手修改內核代碼之前，理解要修改的代碼如何運作是必需的。要達到這個
目的，沒什麼辦法比直接讀代碼更有效了（大多數花招都會有相應的注釋），而且
一些特製的工具還可以提供幫助。例如，「Linux代碼交叉引用」項目就是一個值得
特別推薦的幫助工具，它將源代碼顯示在有編目和索引的網頁上。其中一個更新及
時的內核源碼庫，可以通過以下地址訪問：
http://sosdg.org/~coywolf/lxr/

開發流程
--------

目前Linux內核開發流程包括幾個「主內核分支」和很多子系統相關的內核分支。這
些分支包括：
- 2.6.x主內核源碼樹
- 2.6.x.y -stable內核源碼樹
- 2.6.x -git內核補丁集
- 2.6.x -mm內核補丁集
- 子系統相關的內核源碼樹和補丁集

2.6.x內核主源碼樹
-----------------
2.6.x內核是由Linus Torvalds（Linux的創造者）親自維護的。你可以在
kernel.org網站的pub/linux/kernel/v2.6/目錄下找到它。它的開發遵循以下步
驟：
- 每當一個新版本的內核被發布，為期兩周的集成窗口將被打開。在這段時間里
維護者可以向Linus提交大段的修改，通常這些修改已經被放到-mm內核中幾個
星期了。提交大量修改的首選方式是使用git工具（內核的代碼版本管理工具
，更多的信息可以在http://git.or.cz/獲取），不過使用普通補丁也是可以
的。
- 兩個星期以後-rc1版本內核發布。之後只有不包含可能影響整個內核穩定性的
新功能的補丁才可能被接受。請注意一個全新的驅動程序（或者文件系統）有
可能在-rc1後被接受是因為這樣的修改完全獨立，不會影響其他的代碼，所以
沒有造成內核退步的風險。在-rc1以後也可以用git向Linus提交補丁，不過所
有的補丁需要同時被發送到相應的公眾郵件列表以征詢意見。
- 當Linus認為當前的git源碼樹已經達到一個合理健全的狀態足以發布供人測試
時，一個新的-rc版本就會被發布。計劃是每周都發布新的-rc版本。
- 這個過程一直持續下去直到內核被認為達到足夠穩定的狀態，持續時間大概是
6個星期。
- 以下地址跟蹤了在每個-rc發布中發現的退步列表：
http://kernelnewbies.org/known_regressions

關於內核發布，值得一提的是Andrew Morton在linux-kernel郵件列表中如是說：
「沒有人知道新內核何時會被發布，因為發布是根據已知bug的情況來決定
的，而不是根據一個事先制定好的時間表。」

2.6.x.y -stable（穩定版）內核源碼樹
-----------------------------------
由4個數字組成的內核版本號說明此內核是-stable版本。它們包含基於2.6.x版本
內核的相對較小且至關重要的修補，這些修補針對安全性問題或者嚴重的內核退步。

這種版本的內核適用於那些期望獲得最新的穩定版內核並且不想參與測試開發版或
者實驗版的用戶。

如果沒有2.6.x.y版本內核存在，那麼最新的2.6.x版本內核就相當於是當前的穩定
版內核。

2.6.x.y版本由「穩定版」小組（郵件地址<[email protected]>）維護，一般隔周發
布新版本。

內核源碼中的Documentation/stable_kernel_rules.txt文件具體描述了可被穩定
版內核接受的修改類型以及發布的流程。

2.6.x -git補丁集
----------------
Linus的內核源碼樹的每日快照，這個源碼樹是由git工具管理的（由此得名）。這
些補丁通常每天更新以反映Linus的源碼樹的最新狀態。它們比-rc版本的內核源碼
樹更具試驗性質，因為這個補丁集是全自動生成的，沒有任何人來確認其是否真正
健全。

2.6.x -mm補丁集
---------------
這是由Andrew Morton維護的試驗性內核補丁集。Andrew將所有子系統的內核源碼
和補丁拼湊到一起，並且加入了大量從linux-kernel郵件列表中採集的補丁。這個
源碼樹是新功能和補丁的試煉場。當補丁在-mm補丁集里證明了其價值以後Andrew
或者相應子系統的維護者會將補丁發給Linus以便集成進主內核源碼樹。

在將所有新補丁發給Linus以集成到主內核源碼樹之前，我們非常鼓勵先把這些補
丁放在-mm版內核源碼樹中進行測試。

這些內核版本不適合在需要穩定運行的系統上運行，因為運行它們比運行任何其他
內核分支都更具有風險。

如果你想為內核開發進程提供幫助，請嘗試並使用這些內核版本，並在
linux-kernel郵件列表中提供反饋，告訴大家你遇到了問題還是一切正常。

通常-mm版補丁集不光包括這些額外的試驗性補丁，還包括發布時-git版主源碼樹
中的改動。

-mm版內核沒有固定的發布周期，但是通常在每兩個-rc版內核發布之間都會有若干
個-mm版內核發布（一般是1至3個）。

子系統相關內核源碼樹和補丁集
----------------------------
相當一部分內核子系統開發者會公開他們自己的開發源碼樹，以便其他人能了解內
核的不同領域正在發生的事情。如上所述，這些源碼樹會被集成到-mm版本內核中。

下面是目前可用的一些內核源碼樹的列表：
通過git管理的源碼樹：
- Kbuild開發源碼樹， Sam Ravnborg <[email protected]>
git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git

- ACPI開發源碼樹, Len Brown <[email protected]>
git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git

- 塊設備開發源碼樹, Jens Axboe <[email protected]>
git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git

- DRM開發源碼樹, Dave Airlie <[email protected]>
git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git

- ia64開發源碼樹, Tony Luck <[email protected]>
git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git

- ieee1394開發源碼樹, Jody McIntyre <[email protected]>
git.kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git

- infiniband開發源碼樹, Roland Dreier <[email protected]>
git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

- libata開發源碼樹, Jeff Garzik <[email protected]>
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

- 網路驅動程序開發源碼樹, Jeff Garzik <[email protected]>
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git

- pcmcia開發源碼樹, Dominik Brodowski <[email protected]>
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git

- SCSI開發源碼樹, James Bottomley <[email protected]>
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git

使用quilt管理的補丁集：
- USB, PCI, 驅動程序核心和I2C, Greg Kroah-Hartman <[email protected]>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
- x86-64, 部分i386, Andi Kleen <[email protected]>
ftp.firstfloor.org:/pub/ak/x86_64/quilt/

其他內核源碼樹可以在http://git.kernel.org的列表中和MAINTAINERS文件里
找到。

報告bug
-------

bugzilla.kernel.org是Linux內核開發者們用來跟蹤內核Bug的網站。我們鼓勵用
戶在這個工具中報告找到的所有bug。如何使用內核bugzilla的細節請訪問：
http://test.kernel.org/bugzilla/faq.html

內核源碼主目錄中的REPORTING-BUGS文件里有一個很好的模板。它指導用戶如何報
告可能的內核bug以及需要提供哪些信息來幫助內核開發者們找到問題的根源。

利用bug報告
-----------

練習內核開發技能的最好辦法就是修改其他人報告的bug。你不光可以幫助內核變
得更加穩定，還可以學會如何解決實際問題從而提高自己的技能，並且讓其他開發
者感受到你的存在。修改bug是贏得其他開發者贊譽的最好辦法，因為並不是很多
人都喜歡浪費時間去修改別人報告的bug。

要嘗試修改已知的bug，請訪問http://bugzilla.kernel.org網址。如果你想獲得
最新bug的通知，可以訂閱bugme-new郵件列表（只有新的bug報告會被寄到這里）
或者訂閱bugme-janitor郵件列表（所有bugzilla的變動都會被寄到這里）。

https://lists.linux-foundation.org/mailman/listinfo/bugme-new
https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors

郵件列表
--------

正如上面的文檔所描述，大多數的骨幹內核開發者都加入了Linux Kernel郵件列
表。如何訂閱和退訂列表的細節可以在這里找到：
http://vger.kernel.org/vger-lists.html#linux-kernel
網上很多地方都有這個郵件列表的存檔(archive)。可以使用搜索引擎來找到這些
存檔。比如：
http://dir.gmane.org/gmane.linux.kernel
在發信之前，我們強烈建議你先在存檔中搜索你想要討論的問題。很多已經被詳細
討論過的問題只在郵件列表的存檔中可以找到。

大多數內核子系統也有自己獨立的郵件列表來協調各自的開發工作。從
MAINTAINERS文件中可以找到不同話題對應的郵件列表。

很多郵件列表架設在kernel.org伺服器上。這些列表的信息可以在這里找到：
http://vger.kernel.org/vger-lists.html

在使用這些郵件列表時，請記住保持良好的行為習慣。下面的鏈接提供了與這些列
表（或任何其它郵件列表）交流的一些簡單規則，雖然內容有點濫竽充數。
http://www.albion.com/netiquette/

當有很多人回復你的郵件時，郵件的抄送列表會變得很長。請不要將任何人從抄送
列表中刪除，除非你有足夠的理由這么做。也不要只回復到郵件列表。請習慣於同
一封郵件接收兩次（一封來自發送者一封來自郵件列表），而不要試圖通過添加一
些奇特的郵件頭來解決這個問題，人們不會喜歡的。

記住保留你所回復內容的上下文和源頭。在你回復郵件的頂部保留「某某某說到……」
這幾行。將你的評論加在被引用的段落之間而不要放在郵件的頂部。

如果你在郵件中附帶補丁，請確認它們是可以直接閱讀的純文本（如
Documentation/SubmittingPatches文檔中所述）。內核開發者們不希望遇到附件
或者被壓縮了的補丁。只有這樣才能保證他們可以直接評論你的每行代碼。請確保
你使用的郵件發送程序不會修改空格和製表符。一個防範性的測試方法是先將郵件
發送給自己，然後自己嘗試是否可以順利地打上收到的補丁。如果測試不成功，請
調整或者更換你的郵件發送程序直到它正確工作為止。

總而言之，請尊重其他的郵件列表訂閱者。

❷ linux內核主要由哪幾個部分組成

一個完整的Linux內核一般由5部分組成，它們分別是內存管理、進程管理、進程間通信、虛擬文件系統和網路介面。

1、內存管理
內存管理主要完成的是如何合理有效地管理整個系統的物理內存，同時快速響應內核各個子系統對內存分配的請求。

Linux內存管理支持虛擬內存，而多餘出的這部分內存就是通過磁碟申請得到的，平時系統只把當前運行的程序塊保留在內存中，其他程序塊則保留在磁碟中。在內存緊缺時，內存管理負責在磁碟和內存間交換程序塊。

2、進程管理
進程管理主要控制系統進程對CPU的訪問。當需要某個進程運行時，由進程調度器根據基於優先順序的調度演算法啟動新的進程。：Linux支持多任務運行，那麼如何在一個單CPU上支持多任務呢？這個工作就是由進程調度管理來實現的。

在系統運行時，每個進程都會分得一定的時間片，然後進程調度器根據時間片的不同，選擇每個進程依次運行，例如當某個進程的時間片用完後，調度器會選擇一個新的進程繼續運行。

由於切換的時間和頻率都非常的快，由此用戶感覺是多個程序在同時運行，而實際上，CPU在同一時間內只有一個進程在運行，這一切都是進程調度管理的結果。

3、進程間通信
進程間通信主要用於控制不同進程之間在用戶空間的同步、數據共享和交換。由於不用的用戶進程擁有不同的進程空間，因此進程間的通信要藉助於內核的中轉來實現。

一般情況下，當一個進程等待硬體操作完成時，會被掛起。當硬體操作完成，進程被恢復執行，而協調這個過程的就是進程間的通信機制。

4、虛擬文件系統
Linux內核中的虛擬文件系統用一個通用的文件模型表示了各種不同的文件系統，這個文件模型屏蔽了很多具體文件系統的差異，使Linux內核支持很多不同的文件系統。

這個文件系統可以分為邏輯文件系統和設備驅動程序：邏輯文件系統指Linux所支持的文件系統，例如ext2、ext3和fat等；設備驅動程序指為每一種硬體控制器所編寫的設備驅動程序模塊。

5、網路介面
網路介面提供了對各種網路標準的實現和各種網路硬體的支持。網路介面一般分為網路協議和網路驅動程序。網路協議部分負責實現每一種可能的網路傳輸協議。

網路設備驅動程序則主要負責與硬體設備進行通信，每一種可能的網路硬體設備都有相應的設備驅動程序。

(2)linux內核除法擴展閱讀：

Linux 操作系統的誕生、發展和成長過程始終依賴著五個重要支柱：UNIX操作系統、MINIX操作系統、GNU計劃、POSIX標准和Internet 網路。

1981 年IBM公司推出微型計算機IBM PC。

1991年，GNU計劃已經開發出了許多工具軟體，最受期盼的GNU C編譯器已經出現，GNU的操作系統核心HURD一直處於實驗階段，沒有任何可用性，實質上也沒能開發出完整的GNU操作系統，但是GNU奠定了Linux用戶基礎和開發環境。

1991年初，林納斯·托瓦茲開始在一台386sx兼容微機上學習minix操作系統。1991年4月，林納斯·托瓦茲開始醞釀並著手編制自己的操作系統。

1991 年4 月13 日在comp.os.minix 上發布說自己已經成功地將bash 移植到了minix 上，而且已經愛不釋手、不能離開這個shell軟體了。

1993年，大約有100餘名程序員參與了Linux內核代碼編寫/修改工作，其中核心組由5人組成，此時Linux 0.99的代碼大約有十萬行，用戶大約有10萬左右。

1994年3月，Linux1.0發布，代碼量17萬行，當時是按照完全自由免費的協議發布，隨後正式採用GPL協議。

1995年1月，Bob Young創辦了RedHat（小紅帽），以GNU/Linux為核心，集成了400多個源代碼開放的程序模塊，搞出了一種冠以品牌的Linux，即RedHat Linux,稱為Linux"發行版"，在市場上出售。這在經營模式上是一種創舉。

2001年1月，Linux 2.4發布，它進一步地提升了SMP系統的擴展性，同時它也集成了很多用於支持桌面系統的特性：USB，PC卡（PCMCIA）的支持，內置的即插即用，等等功能。

2003年12月，Linux 2.6版內核發布，相對於2.4版內核2.6在對系統的支持都有很大的變化。

2004年的第1月，SuSE嫁到了Novell，SCO繼續頂著罵名四處強行「化緣」， Asianux， MandrakeSoft也在五年中首次宣布季度贏利。3月，SGI宣布成功實現了Linux操作系統支持256個Itanium 2處理器。

❸ 你好，我想問一下，就是linux裡面用除法這個問題你解決了嗎想求教一下，我遇到這個問題搞了好幾天了。

整除 echo $(( 10/3 ))

保留兩位小數 echo "scale=2;10/3" |bc

❹ linux系統,對於求余和除法運算量大嗎

可以參考以下資料
在進行shell編程時，我們可以藉助expr指令來完成整數的算術運算。可進行的算術運算有：加法（符號：+）、減法（符號：-）、乘法（符號：*）、除法（符號：/）、求余（符號：%）及賦值（符號：=）。下面一個例子說明算術運算符的使用及注意事項。
我們使用了所有算術運算符，但編寫樣式是不全相同的，具體它的運行結果是如何呢？我在終端中，運行上述shell文件
代碼對賦值運算符使用時，有所區別。加法、減法賦值運算符左右兩側均無空格，而乘法在賦值符左側有空格，右側無空格，除法和求余則賦值符左右都有空格，從運行結果可知，僅有加法、減法運行正常。

❺ 如何進行linux內核開發

內核幾乎全是用C寫成的，有一些架構相關的部分是用匯編語言寫成的。熟練掌握C語言是內核開發的必備條件。匯編語言(任何架構)的了解不是必須的，除非你准備做某個架構的底層開發。雖然下面這些書不能完全代替扎實的C語言教學和/或者成年累月的經驗，他們還是不錯的參考，如果用得著的話： - "The C Programming Language" 作者: Kernighan and Ritchie [Prentice Hall]- "Practical C Programming" 作者: Steve Oualline [O'Reilly] 內核是用 GNU C 和 GNU 工具鏈寫成的。雖然它符合 ISO C89 標准，它還是使用了一些標准中沒有的擴展。內核是自成體系的 C 環境，它並不依賴標准C庫，所以某些C語言標準是不支持的。任意長度long long類型除法和浮點數是不被允許的。有時候會很難理解內核對於它所使用的工具鏈和擴展的假定，而且不幸的是也沒有關於它們的絕對的參考。請查閱gcc 的info頁(`info gcc`)以獲取有關信息。 他們發現遵循這些標准對於這樣一個大規模的且地理上分散的團隊是最佳的選擇。嘗試提前學習盡可能多的有關這些標準的知識，因為它們都有很好的文檔；不要期望別人會遵照你或

❻ Linux：關於除法運算的小數點問題

echo752/802|bc-l|sed's/^./0&/'

❼ 如何刪除linux舊內核

在刪除舊內核之前，記住最好留有2個最近的內核（最新的和上一個版本），以防主要的版本出錯。現在就讓我們看看如何在Ubuntu上清理舊內核。在Ubuntu內核鏡像包含了以下的包。
linux-image-: 內核鏡像
linux-image-extra-: 額外的內核模塊
linux-headers-: 內核頭文件

首先檢查系統中安裝的內核鏡像。
$ dpkg --list | grep linux-image
$ dpkg --list | grep linux-headers

在列出的內核鏡像中，你可以移除一個特定的版本（比如3.19.0-15）。
$ sudo apt-get purge linux-image-3.19.0-15
$ sudo apt-get purge linux-headers-3.19.0-15
上面的命令會刪除內核鏡像和它相關聯的內核模塊和頭文件。

注意如果你還沒有升級內核那麼刪除舊內核會自動觸發安裝新內核。這樣在刪除舊內核之後，GRUB配置會自動升級來移除GRUB菜單中相關GRUB入口。
如果你有很多沒用的內核，你可以用shell表達式來一次性地刪除多個內核。注意這個括弧表達式只在bash或者兼容的shell中才有效。
$ sudo apt-get purge linux-image-3.19.0-{18,20,21,25}
$ sudo apt-get purge linux-headers-3.19.0-{18,20,21,25}
上面的命令會刪除4個內核鏡像：3.19.0-18、3.19.0-20、3.19.0-21 和 3.19.0-25。

如果GRUB配置由於任何原因在刪除舊內核後沒有正確升級，你可以嘗試手動用update-grub2命令來更新配置。
$ sudo update-grub2
現在就重啟來驗證GRUB菜單是否已經正確清理了。

❽ linux 除法保留小數

因為int 是整數，整數除整數就是整數
double是小數。小數除小數才是小數
有兩種方法，
1.是直接用小數除
如3.0/5.0
這樣編譯器會認為他們是double類型
2.是轉換成double，或直接定義成double
如double a=3;
double b=5;
System.out.println(3/5);
還有什麼不懂可以HI我

❾ linux除法保留小數

你可以這樣
res=$(printf "%.5f" `echo "scale=5;1/3"|bc`)
%.5f 和 scale=5都表示小數點後面取5位

❿ lpc2103 報錯aeabi_uidiv

解決思路：
1、這個錯誤提示說明是一個未定義引用的錯誤，根據__aeabi_uidivmod，和__aeabi_uidiv猜想應該是除法實現的問題（為什麼就能得出是除法實現的問題？根據英文名嗎？可是我查了下，沒有這個英文。）。
2、這里用到了lib1funcs.S這個除法庫文件，於是在裡面搜索__aeabi_uidiv和__aeabi_uidivmod，找不到這兩個關鍵字的定義。
說明應該是4.3.2版本的編譯工具需要找這兩個關鍵字的定義，但是找不到。
3、猜測應該是這個lib1funcs.S是比較老版本的庫文件，可是這個較新版本的去哪找呢，除法運算在u-boot和Linux內核里肯定實現了，就到這兩個裡面去找這個文件。
4、4.3.2編譯通過的兩個項目版本分別是u-boot-2012.04.01以及linux-3.4.2，就到這兩個項目中找，你會發現u-boot裡面沒有這個文件，u-boot肯定實現了，但是不是用這個來實現的，我們到linux內核里找：
find /work/projects/linux-3.4.2 -name "lib1funcs.S"
搜索結果：

./arch/arm/lib/lib1funcs.S
./arch/arm/boot/compressed/lib1funcs.S
登錄後復制
5、/work/system/linux-3.4.2/arch/arm/lib/lib1funcs.S，這個文件應該就是我們找的庫文件。
把他到項目里，然後make。
編譯結果：

arm-linux-gcc -c -o lib1funcs.o lib1funcs.S
lib1funcs.S:36:27: error: linux/linkage.h: No such file or directory
lib1funcs.S:37:27: error: asm/assembler.h: No such file or directory
lib1funcs.S:38:24: error: asm/unwind.h: No such file or directory
Makefile:11: recipe for target 'lib1funcs.o' failed
make: *** [lib1funcs.o] Error 1
登錄後復制
提示我們找不到這些頭文件，對比以前的lib1funcs.S不需要這些頭文件。
所以我們把頭文件注釋掉：

35 /*
36 #include <linux/linkage.h>
37 #include <asm/assembler.h>
38 #include <asm/unwind.h>
39 */
登錄後復制
6、再次編譯，出現如下錯誤：

arm-linux-gcc -c -o lib1funcs.o lib1funcs.S
lib1funcs.S: Assembler messages:
lib1funcs.S:181: Error: bad instruction `entry(__udivsi3)'
lib1funcs.S:182: Error: bad instruction `entry(__aeabi_uidiv)'
lib1funcs.S:183: Error: bad instruction `unwind(.fnstart)'
lib1funcs.S:207: Error: bad instruction `unwind(.fnend)'
lib1funcs.S:208: Error: bad instruction `endproc(__udivsi3)'
lib1funcs.S:209: Error: bad instruction `endproc(__aeabi_uidiv)'
lib1funcs.S:211: Error: bad instruction `entry(__umodsi3)'
lib1funcs.S:212: Error: bad instruction `unwind(.fnstart)'
lib1funcs.S:226: Error: bad instruction `unwind(.fnend)'
lib1funcs.S:227: Error: bad instruction `endproc(__umodsi3)'
lib1funcs.S:229: Error: bad instruction `entry(__divsi3)'
lib1funcs.S:230: Error: bad instruction `entry(__aeabi_idiv)'
lib1funcs.S:231: Error: bad instruction `unwind(.fnstart)'
lib1funcs.S:268: Error: bad instruction `unwind(.fnend)'
lib1funcs.S:269: Error: bad instruction `endproc(__divsi3)'
lib1funcs.S:270: Error: bad instruction `endproc(__aeabi_idiv)'
lib1funcs.S:272: Error: bad instruction `entry(__modsi3)'
lib1funcs.S:273: Error: bad instruction `unwind(.fnstart)'
lib1funcs.S:293: Error: bad instruction `unwind(.fnend)'
lib1funcs.S:294: Error: bad instruction `endproc(__modsi3)'
lib1funcs.S:356: Error: bad instruction `unwind(.fnstart)'
lib1funcs.S:357: Error: bad instruction `unwind(.pad #4)'
lib1funcs.S:358: Error: bad instruction `unwind(.save {lr})'
lib1funcs.S:363: Error: bad instruction `unwind(.fnend)'
lib1funcs.S:364: Error: bad instruction `endproc(Ldiv0)'
Makefile:11: recipe for target 'lib1funcs.o' failed
make: *** [lib1funcs.o] Error 1
登錄後復制

應該是去掉頭文件引起的編譯器對定義不理解。
對比老版本的lib1funcs開頭有一些宏定義我們先加上：

#define ALIGN .align 4,0x90
#define __LINUX_ARM_ARCH__ 1

#define ENTRY(name) \
.globl name; \
ALIGN; \
name:
登錄後復制
其中有entry的宏定義，我們可以猜想這些都是在頭文件里的宏定義，其實你去linux內核里找這個頭文件#include <linux/linkage.h>在這里就可以找到entry的宏定義。

7、再次編譯，出現錯誤：

[email protected]:/work/test$ make
arm-linux-gcc -c -o lib1funcs.o lib1funcs.S
lib1funcs.S: Assembler messages:
lib1funcs.S:192: Error: bad instruction `unwind(.fnstart)'
lib1funcs.S:216: Error: bad instruction `unwind(.fnend)'
lib1funcs.S:217: Error: bad instruction `endproc(__udivsi3)'
lib1funcs.S:218: Error: bad instruction `endproc(__aeabi_uidiv)'
lib1funcs.S:221: Error: bad instruction `unwind(.fnstart)'
lib1funcs.S:235: Error: bad instruction `unwind(.fnend)'
lib1funcs.S:236: Error: bad instruction `endproc(__umodsi3)'
lib1funcs.S:240: Error: bad instruction `unwind(.fnstart)'
lib1funcs.S:277: Error: bad instruction `unwind(.fnend)'
lib1funcs.S:278: Error: bad instruction `endproc(__divsi3)'
lib1funcs.S:279: Error: bad instruction `endproc(__aeabi_idiv)'
lib1funcs.S:282: Error: bad instruction `unwind(.fnstart)'
lib1funcs.S:302: Error: bad instruction `unwind(.fnend)'
lib1funcs.S:303: Error: bad instruction `endproc(__modsi3)'
lib1funcs.S:365: Error: bad instruction `unwind(.fnstart)'
lib1funcs.S:366: Error: bad instruction `unwind(.pad #4)'
lib1funcs.S:367: Error: bad instruction `unwind(.save {lr})'
lib1funcs.S:372: Error: bad instruction `unwind(.fnend)'
lib1funcs.S:373: Error: bad instruction `endproc(Ldiv0)'
Makefile:11: recipe for target 'lib1funcs.o' failed
make: *** [lib1funcs.o] Error 1
登錄後復制

unwind() 和unwind()的宏定義老版本里沒有，怎麼辦呢？
全部注釋掉：

#UNWIND(.fnend)
#ENDPROC(__modsi3)
登錄後復制
8、再次編譯，出現錯誤：

[email protected]:/work/test$ make
arm-linux-gcc -c -o lib1funcs.o lib1funcs.S
#arm-linux-ld -Ttext 0 -Tdata 0x30000000 start.o led.o uart.o init.o main.o -o sdram.elf
arm-linux-ld -T sdram.lds start.o led.o uart.o init.o main.o exception.o interrupt.o timer.o nor_flash.o my_printf.o string_utils.o lib1funcs.o -o sdram.elf
my_printf.o: In function `out_num':
my_printf.c:(.text+0x120): undefined reference to `__aeabi_uidivmod'
lib。

LPC2103
LP