1樓：
比如linux程序鍊錶、紅黑樹中list_head、hlist_head、rb_node等，
把資料結構放在結構體中，而不是把結構體放在資料結構中，再通過container_of()根據結構體中的元素相對位置找到相應的結構體。
ps：感覺看linux核心就像學獨孤九劍，學的時候晦澀難懂，但每看懂一部分又覺得精妙絕倫
2樓：iterator
說乙個kernel中用的很普遍的細節吧，即list_head結構。多個list_head可串成鍊錶，這些鍊錶節點一般包含在某結構體中，再巧妙地用list_head對應的字段在結構體中的偏移量（container_of巨集）獲得所屬結構體的指標。這樣的巧妙做法讓鍊錶這一結構有了統一的維護標準，無疑大大增強了kernel原始碼的可維護性。
3樓：zhiyuan
Linux核心的愛好者，就讓我以Linux核心來回答這個問題吧：
1. 我大VFS！通過VFS的抽象層，一切都變成了檔案。
於是Linux的系統呼叫精簡了好多，於是很多虛擬檔案系統(proc, sysfs, cgroup, tmpfs)得以實現，於是linux可以相對容易的支援多種檔案系統。
2. current巨集的實現。將核心棧建立在當前的程序描述符的上面，通過棧位址偏移即可快速獲得當前程序的資訊。
3. clone系統呼叫。模糊了程序，執行緒的界線，在linux核心中沒有明確的執行緒、程序的概念，都是task_struct表示的執行例項，且依據clone的引數，例項間靈活的可以共享多種資訊。
而共享程度的兩種特殊情況，就是程序和執行緒。
4. cgroup, namespace。核心居然要虛擬化程序的執行環境！也成就了Docker。
5. 紅黑樹的陣列做hash結構。用紅黑樹而非鍊錶來組織雜湊衝突的元素(原始碼中部分雜湊是這樣的)。
6. CFS排程器。通過紅黑樹、vruntime等將之前多鍊錶表示不同優先順序的排程演算法簡化，妙！
7. ……（核心的學習是乙個充滿了驚喜的旅程，路途遙遠，允許我以沒有結尾的結尾來做個結尾吧！）
4樓：下愚
為了不讓明珠蒙塵，這裡介紹一下FreeBSD核心中的遞迴頁表，下面是多年前整理的內容。
在分層的頁表中，如果在最高層的頁目錄中增加乙個指向自己的頁目錄指標，就能把頁表項（pte），頁目錄項（pde）抽象為一系列陣列，從而高效的查詢任意虛擬位址對應的pte,pde或者實體地址。這甚至是一項專利，http://www.
在FreeBSD i386中，相關介面定義為，
extern pt_entry_t PTmap;
extern pd_entry_t PTD;
extern pd_entry_t PTDpde;
#define vtopte(va) (PTmap + i386_btop(va))
假設系統中頁表分為N層，那麼乙個虛擬位址分為(N+1)部分()，
是頁內偏移量，把每層頁表都當做陣列，並且最高層陣列定義為T，並且其A項指向自己，即T[A] = T，那麼有
記第i層頁表為(i = 0, 1, 2, ..., N - 1)，則，
/* 第乙個想出這種技巧的人真是太聰明了。*/
@李鑫 有請行家指正 :-)
5樓：沒什麼技術
我研究的是linux作業系統，我覺得最出彩還是記憶體管理這部分。每個程序都有乙個程序描述符，然後程序的記憶體空間由程序描述符的屬性記憶體描述符管理，分為一段一段的vma。當分配記憶體時，先分配虛擬記憶體，當訪問這塊記憶體時，產生記憶體缺頁，在由核心夥伴系統分配物理記憶體對映～加了一層虛擬記憶體空間，這樣相當於每個程序都有3G的使用者空間，即使物理記憶體並沒有那麼多～而且即使物理記憶體用完了，還支援swaped out到交換區，給人感覺記憶體取之不盡，用之不竭(;｀O)o～
6樓：wishes2018
1.程序排程：優先順序與時間片計算。程序佇列中可執行佇列(還有時間片)與過期佇列(時間片耗盡的)交叉替換。
2.記憶體分配策略：夥伴演算法與slab演算法。
3.快閃儲存器檔案系統：借鑑了yaffs檔案系統。
演算法倒是沒有很出彩的地方。資料結構覺得不錯。由於快閃儲存器的特性(寫入之前要擦除，擦除需要整個塊擦除)，沒辦法把檔案系統的結構資訊固定的儲存在某個位置，所以只能通過掃瞄整個flash，收集分布在各地的檔案節點，在記憶體中構建檔案系統結構。
7樓：
大多數都是linux/windows下的， 來個rtos的. 比如ucos
實時作業系統就和消費級用的系統對時間的敏感度不一樣了，手機卡個十幾ms，人類也感覺不出來啥，但是工控/航天等領域那都是按us來算的，上學的時候做電流控制就在那天天糾結1us波形的事兒呢； 介紹乙個ucos中的基石資料結構（演算法），簡單實用.
補充下思想好的原因，以前就是覺著很奇妙，沒細想.
->如果查詢表這個資料結構或演算法是比較通用的話，那麼本身就很普通了，不過想想，如果我設計，冥思苦想發現可以查詢表，那麼毫無疑問，我會設計成64位的二進位制數，那就要儲存計算這麼多個數，又傻又蠢.
->精妙之處在於，結合了任務優先順序演算法的需求：即找到最小置1的位。 而分離出來優先順序判定表而大大減少了查詢表的個數.
任務控制快的管理儲存與演算法
預備： 除了空閒任務和統計任務之外，作業系統還執行著各種使用者建立任務，這些任務優先順序不一樣，狀態不同，ucos預設可以有64個任務，可剝奪型核心，也就是系統中時刻執行著最高優先順序的任務，排程任務的核心就是基於任務的優先順序演算法（不會像非剝奪型核心一樣任務會一直阻塞在能力直至完成）， 那麼就要求根據中斷時間（根據不同的硬體封裝的）週期到了就要查詢當前系統中就緒任務優先順序最高的執行，ucos的每個任務維護著乙個任務控制快，其中包括任務堆疊資訊和優先順序等，思路也很好想，遍歷任務控制塊好了，找到優先順序最低的那個執行不就行了，windows可以接受，對於RTOS就不行啦，運氣好第乙個就找到了，運氣不好那最後乙個，時間豈不是很長？ucos給出的解決方法是--查詢表.
資料結構：
1. 首先把任務位址放在優先順序指標表裡面，那麼如果知道最高優先順序的話，對應的任務也可以隨機儲存了
OS_TCB *OSTCBPrioTbl[OS_LOWEST_PRIO + 1]
2. 接下來主要就是找優先順序最高的任務了，如果最大任務總數是64個，也就是有64個優先順序，實際上可以用64為來標示，每乙個優先順序是否有任務是就緒態，1就是就緒，0是沒有任務或者有任務沒有就緒，遍歷的做法是直接找最小位就可以了（數字越小優先順序越高），查表發結構如下：
INT8U OSRdyGrp
INT8U OSRdyTbl[8]
這樣，64個優先順序分成了8組，每個組有8位， 只要是該優先順序處於就緒態的那就是1了. 只要這一組有乙個位數是1，那麼OSRdyGrp對應位數就是1，否則是零，實際上要找的最高優先順序就是從低位開始遇到到的第乙個1， 每乙個OSRdyGrp OSRdyTbl都代表了當前任務的狀態.,
既然是查詢表，思路就是不把不同狀態值固話到記憶體（表）中以供查詢。優先順序判定表：
INT8U const OSUnMapTbl[2560, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
5, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
6, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
5, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
7, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
5, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
6, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
5, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0,
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0
};公式如下：
y = OSUnMapTbl[OSRdyGrp1
OSPrioHighRdy = (y << 3) + OSUnMapTbl[OSRdyTbl[y2
先來理解1, 2也就理解了， 對於就緒組來說，無論8位二進位制數（256），無論怎麼組合都在256個範圍內，而對於任何一種組合來說，最低位數就是確定的，這即使查詢表應用的核心（對映是唯一的），比如OSUnMapTbl[4]吧，二進位制100，顯然最低在二組（還有0組），即最高的優先順序肯定在這組，y<<3用來累計了前面組的任務數； 同樣 OSRdyTbl[y] 的結果是當前組的狀態位，放到OSUnMapTbl中查詢，找到的就是最低位1所在的位（基於當前組） ，加上前面累計的優先順序個數，得到的就是當前的最高優先順序； 最後再到最開始提到的任務指標表中找到任務堆疊，最高優先順序任務就找到了，
OSTCBPrioTbl
可以看到，無論是任務指標表還是優先順序狀態表的查詢，都是隨機訪問的，無論是設定還是查詢，時間都是恆定不變且是最短的，滿足了RTOS對任務排程演算法的要求. 簡單（？）高效
乙個作業系統可以有多個核心嗎 是怎樣實現的
jiangtao9999 RT Linux 就是多核心設計。我記得 RT Linux 靠 CPU 的多核心做隔離，Linux 核心靠乙個抽象層執行在實時核心之上。其實你完全可以先做乙個只支援虛擬機器的核心，直接核心級的虛擬機器，之後在虛擬機器上去跑子系統。當然，邏輯上，這些其實是單核心，其他的核心只...
作業系統核心編寫是否可以用STL
開發核心還是用自底向上的方法開發。STL可以作為實現的參考，直接呼叫很多細節的東西不在控制內，有可能對核心效能 依賴性和可移植性產生影響。本著底層的東西能自己寫就自己寫的原則，僅供參考。重新看了下你的問題，是可以的。還有，STL的可讀性不差的。 韋易笑 能不能用先不說，想想stl版本的linux核心...
如何評價華為的自動駕駛作業系統核心獲得ASIL D的認證？
biubiu 成為中國首個獲得ASIL D認證的作業系統核心，同時該核心已於2019年9月獲得Security領域高等級資訊保安認證 CCEAL5 標誌著華為自動駕駛作業系統核心已成為業界首個擁有SecuritySafety雙高認證的商用OS核心。 洱海之東 先來看看這個證書的含金量，ISO 262...