커널은 運營 體制의 核心 部分이므로, 커널의 役割 亦是 運營 體制의 核心 役割이라 할 수 있다.

• 保安

커널은 컴퓨터 하드웨어 와 프로세스 의 保安 을 責任진다.

• 資源 管理

限定된 시스템 資源을 效率的으로 管理하여 프로그램 의 實行을 원활하게 한다. 特히 프로세스에 處理機를 割當하는 것을 스케줄링이라 한다.

• 抽象畫

같은 種類의 部品 에 對해 다양한 하드웨어 를 設計할 수 있기 때문에 하드웨어에 直接 接近하는 것은 問題를 매우 複雜하게 만들 수 있다. 一般的으로 커널은 運營 體制의 複雜한 內部를 감추고 깔끔하고 一貫性 있는 인터페이스 를 하드웨어에 提供하기 위해 몇 가지 하드웨어 抽象化 (같은 種類의 裝備에 對한 共通 命令語의 集合)들을 具現한다. 이 하드웨어 抽象化는 프로그래머 가 여러 裝備에서 作動하는 프로그램을 開發하는 것을 돕는다. 하드웨어 抽象化 階層 (HAL)은 除朝辭의 裝備 規格에 對한 특정한 命令語를 提供하는 소프트웨어 드라이버 에 依支한다.

初期의 커널 編輯

草創期의 컴퓨터에서 運營 體制 커널은 必須的인 것이 아니었다. 初期의 프로그램은 하드웨어 抽象化나 運營 體制의 支援을 받지 않고도 컴퓨터만으로 불러들인 다음 實行될 수 있었으며, 이것은 草創期 컴퓨터들의 一般的인 運營 方式이었다. 다른 프로그램을 實行하기 위해서는 컴퓨터의 電源을 껐다가 켬으로써 다시 入力資料를 읽어들여야 하는 方式이었다. 이러한 過程이 反復되면서 사람들은 로더 와 디버거 같은 작은 프로그램들이 常住해 있는 것이, 다른 프로그램으로 交替하거나 새로운 프로그램을 開發하는 데 유리하다는 事實을 알게 되었다. 이와 같은 로더, 디버거들이 初期 運營 體制 커널의 基礎가 되었다.

• 單一型 커널 (monolithic kernel) - 커널의 다양한 서비스 및 높은 水準의 하드웨어 抽象化를 하나의 덩어리(住所 空間)로 묶은 것이다. 運營 體制 開發者 立場에서 維持 保守가 一般的으로 더 어려우나 性能이 좋다.
• 마이크로커널 (microkernel) - 하드웨어 抽象化에 對한 簡潔한 작은 集合을 提供하고 더 많은 機能은 서버 라고 불리는 應用 소프트웨어를 통해 提供한다.
• 混合型 커널 (hybrid kernel) - 性能 向上을 위해 追加的인 코드를 커널 空間에 넣은 點을 除外하면 많은 部分은 純粹 마이크로커널과 비슷하다. 修正 마이크로커널 이라고도 한다.
• 나노커널 (nanokernel) - 實質的으로 모든 서비스를 責任진다.
• 엑소커널 (exokernel) - 낮은 水準의 하드웨어 接近을 위한 最小限의 抽象化를 提供한다. 典型的으로 엑소커널 시스템에서는 커널이 아닌 라이브러리 가 單一型 커널 水準의 抽象을 提供한다.

單一型 커널 編輯

單一型 커널은 하드웨어 위에 높은 水準의 假想 階層을 定義한다. 높은 水準의 假想 階層은 基本 演算 集合果 管理者 모드 에 作動하는 모듈 人 프로세스 管理, 同時性 , 메모리 管理 等의 運營 體制 서비스를 具現하기 위한 시스템 콜 으로 되어 있다.

이 演算들을 提供하는 모든 모듈이 全體로부터 分離되어 있더라도 모든 모듈이 같은 住所 空間에서 實行되기 때문에 코드의 集積度는 매우 稠密하며 修正하기 어렵고 한 모듈의 버그는 시스템 全般을 멈추게 할 수 있다. 그러나 具現이 信賴할 수 있을 程度로 完成되면 構成 要素의 內部 集積이 內部의 시스템 利用을 效果的이게 하여 좋은 單一型 커널은 높은 效率을 보인다. 單一型 커널의 支持者들은 코드의 正確性 與否와 그런 코드(不正確한 코드)가 커널에 包含되었는지를 確認할 수 있고 그것은 마이크로커널에 비해 조금 더 優位에 있다고 主張한다.

리눅스 , FreeBSD , 솔라리스 와 같은 最新의 單一型 커널은 實行 모듈을 實時間으로 읽어들일 수 있다. 實時間으로 實行 모듈을 읽는 特徵은 커널이 許容하는 範圍 內에서 손쉽게 擴張할 수 있게 커널 空間의 코드의 量을 最小限으로 維持시켜 준다.

마이크로소프트 윈도우 NT 製品群(NT, 2000, XP, 2003, 비스타,7,8,8.1,10)은 처음에는 混合型 커널이었으나 나중에 나온 것들은 單一型 커널로 바뀌었다. 윈도우 NT 시리즈는 上位의 서비스들을 NT executive 이라는 서버로 具現하였다. Win32 特性은 처음에는 使用者 모드의 서버 形態로 具現되었으나, 最近 버전에서는 管理者 住所 領域으로 移動하였다. 다양한 서버들이 로컬 프로시저 콜(LPC: Local Procedure Call)이라 불리는 住所 領域間 매커니즘을 통해 通信하며, 性能을 最適化하기 위해 共有 메모리를 利用한다.

主로 다음 運營 體制들의 커널이 單一型 커널인 것으로 알려져 있다.

• 유닉스
• BSD
• 리눅스
• 솔라리스
• 윈도우 NT
• 벨로나2
• AIX
• AGNIX

마이크로커널 編輯

마이크로커널은 하드웨어 위에 매우 簡潔한 抽象化를 定義한다. 基本 演算 集合果 運營 體制 서비스를 具現한 스레드 管理 , 住所 空間 , 프로세스間 通信 의 작은 시스템 콜 으로 이루어져 있다. 一般的으로 커널이 提供하는 네트워킹 과 같은 다른 서비스들은 使用者 空間 프로그램인 서버 로 具現한다.

運營 體制는 서버를 다른 一般的인 프로그램처럼 簡單히 始作하고 끌 수 있다. 이를테면 네트워킹 支援이 必要 없는 작은 시스템에서는 簡單히 서버를 끄면 된다. 이 境遇 傳統的인 시스템에서는 再컴파일 이 必要했고 一般 使用者의 能力 밖의 일이다. 理論的으로 마이크로커널에서 시스템은 더 安定的이다. 서버가 中斷될 때 커널의 衝突이 아니기 때문에 單 하나의 프로그램만 내려버리면 된다.

그러나 서버가 失敗한 後 시스템 狀態도 잃어버릴 境遇 應用 프로그램이 繼續 遂行되는 것은 그 應用 프로그램이 막 複寫된 다른 서버를 利用하게 되더라도 普通은 매우 힘들다. 例를 들어 TCP/IP 連結을 要求하는 (理論的인) 서버가 다시 始作되면 應用 소프트웨어는 連結이 "끊어졌습니다."라고 말하고 서버의 새 인스턴스를 찾아서 다시 連結한다. 그러나 파일과 같은 다른 시스템 客體는 이렇게 便利한 意味論 이 없다. 이러한 便利가 믿음직스럽지 못하고 마음대로 利用할 수 없다. 記錄할 情報들은 모두 미리 保管해 두어야 한다. 서버 間의 하나의 서버를 다시 始作할 때 重要 狀態를 保護하기 위해 트랜잭션 , 複製 , 對照點 의 데이터베이스 技術이 要求된다.

一般的으로 마이크로커널은 傳統的인 디자인의 遂行을 잘못하고 때로는 劇的이다. 理由는 應用과 서버 間의 資料 交換을 위해 커널을 出入하는 文脈 交換 때문이다. 注意 깊은 調律이 오버헤드를 劇的으로 줄여줄 것으로 믿어져 왔으나 90年代 中盤부터 大部分의 硏究員들은 試圖를 抛棄했다. 最近에 새 마이크로커널은 性能을 最優先으로 設計하며 이 問題를 넓은 部分에서 다루었다. 그러나 現在 運營 體制 市場은 自己 몸 사리며 마이크로커널 設計에 消極的이다.

마이크로커널과 마이크로커널에 基盤한 運營 體制의 예

• AmigaOS
• Amoeba
• ChorusOS
• EROS
• Haiku
• K42
• LSE/OS ( 나노커널 )
• KeyKOS ( 나노커널 )
• L4 마이크로커널
• Mach (커널) - GNU 허드 , 넥스트스텝 , 오픈스텝 , macOS 에 使用됨.
• MERT
• 미닉스
• MorphOS
• NewOS
• QNX
• Phoenix-RTOS
• RadiOS
• Spring operating system
• VSTa
• 심비안 OS

混合型 커널(修正 마이크로커널) 編輯

混合型 커널은 本質的으로 마이크로커널을 따르나, 一部 커널의 비(非)本質的 機能이더라도 使用者 레벨에서 遂行될 때 性能上 느린 코드들을 커널 레벨에서 遂行하도록 修正한 것을 말한다. 이는 다양한 運營 體制 開發者들이 마이크로커널 基盤의 設計를 받아들이던 時點에 純粹한 마이크로커널의 性能上의 限界를 認識하고 妥協한 結果이다.

例를 들어, macOS 의 커널인 XNU 는 Mach 커널 3.0 마이크로커널에 基盤을 두고 있지만, 傳統的인 마이크로커널 設計의 遲延 現象을 줄이기 爲해 BSD 커널의 一部 코드들을 들여와 同一한 住所 領域에서 實行하고 있다.

DragonFly BSD 는 첫 番째 非 Mach 基盤의 BSD OS로 混合型 커널 構成을 適用한 例이다.

하이브리드 커널로는 다음과 같은 것들도 包含된다.

• ReactOS
• BeOS 커널
• 넷웨어 커널

混合型 커널이라는 말을 부팅 後에 모듈을 읽어들일 수 있는 單一型 커널과 混用하는 사람들이 있다. 이것은 事實이 아니다. 混合型 커널은 單一型 커널과 마이크로커널 設計 兩쪽의 構造的 槪念과 作動方法에 對한 特히 메시지 傳達과 어떤 重要하지 않은 코드는 使用者 空間에 들어가는 反面 어떤 코드는 性能의 理由로 커널 空間에 包含해야 하는지에 對한 問題意識을 가진다.

엑소커널 編輯

엑소커널은 運營 體制 設計에 對한 急進的인 新槪念으로 末端 理論 을 따르는 垂直 構造의 運營 體制이다. 엑소커널의 構想은 開發者에게 强制的인 抽象化를 줄여 하드웨어 抽象化에 對해 選擇肢를 다양하게 하는 것이다. 엑소커널은 機能이 保護를 保障하는 것과 資源을 分配 하는 것만 하기에 매우 작아 便益보다 單純함을 提供한다. 이런 特性은 오히려 모든 使用者가 各其 實際 호스트 컴퓨터의 資源을 模倣한 컴퓨터를 받는 VM/370 運營 體制와 비슷하다. 反面에 모놀리식 커널이든 마이크로 커널이든 傳統的인 커널 設計는 하드웨어 抽象化 階層 (HAL)이나 裝置 드라이버 아래 資源을 숨김으로써 하드웨어를 抽象化한다. 한 例로 傳統的인 시스템에서 物理 메모리가 割當할 때 實際 位置를 알려주지 않기 때문에 오프셋과 記憶 管理 裝置 를 통해서만 問題를 解決할 수 있다.

老커널 編輯

TUNES Project [1] 와 UnununiumOS [2] 는 老커널 [3] 實驗이다. 老커널 소프트웨어는 單一 中央 入口의 制約이 없다.

1990年代 初期 모놀리식 커널은 陳腐한 것으로 여겨졌다. 리누스 토르발스 와 앤드류 타넨바움 間에 일어난 리눅스 의 設計인 모놀리식 커널과 마이크로커널에 對한 프레임 워 는 有名했다. [4] [5]

타넨바움과 토르발스의 討論에 提示된 두 陣營의 意見은 一長一短이 있다.

두 陣營의 成功 事例가 있다. 모놀리식 커널은 正確한 設計가 쉽고 마이크로커널 基盤 시스템보다 빨리 成長할 수 있다. 反對로, 마이크로커널은 種種 임베디드 로봇 産業이나 醫療 컴퓨터 等에 利用될 수 있다. 運營 體制의 컴포넌트를 個人的으로 가지고 있고 메모리 空間을 保護하기 때문이다. 近代의 모듈을 읽어오는 모놀리식 커널에서도 이런 것은 不可能하다.

Mach 는 一般的인 用途의 마이크로커널로 알려졌지만 특별한 用途로 設計된 마이크로커널度 있다. L3 는 마이크로커널이 느리지 않다는 것을 보여주기 위해 만들어졌다. L4 는 L3의 後裔로 Fiasco 具現으로 大衆的인데 L4 프로세스들과 別途의 空間에서 리눅스 驅動이 可能하다. 이런 特性의 스크린샷은 freshmeat.net에서 求할 수 있다. Pistachio 라 불리는 새 버전도 亦是 可能하다.

QNX 는 1980年 初에 나타난 運營 體制로 極 최소주의 마이크로커널 設計로 이루어졌다. 이 시스템은 Mach가 目標로 했던 마이크로커널 理念을 더 成功的으로 이루었다. QNX는 宇宙 往復船 의 로봇 팔과 (작은 失手가 數十億의 損失을 입히는 허블 宇宙望遠鏡 의 거울 等의) 誤差에 敏感한 琉璃를 닦는 機械에도 適用되었다.

• 運營 體制
• 셸

• 소스包紙의 運營 體制 커널
• Freshmeat의 運營 體制 커널
• MIT 엑소커널 運營 體制
• KeyKOS 나노커널 救助 , 1992年 노르만 下르디 저
• 넷웨어 運營 體制 槪論 , 1994年 Drew Major, Greg Minshall, Kyle Powell 저 (넷웨어 運營 體制 뒤의 基本 構造).