diff --git "a/_posts/processinalC/chap10.-\354\234\240\353\213\211\354\212\244\354\235\230-\354\227\255\354\202\254\354\231\200-\354\225\204\355\202\244\355\205\215\354\262\230/2023-12-17-\354\235\264\352\260\200\354\235\200-chap10.-\354\234\240\353\213\211\354\212\244\354\235\230-\354\227\255\354\202\254\354\231\200-\354\225\204\355\202\244\355\205\215\354\262\230.md" "b/_posts/processinalC/chap10.-\354\234\240\353\213\211\354\212\244\354\235\230-\354\227\255\354\202\254\354\231\200-\354\225\204\355\202\244\355\205\215\354\262\230/2023-12-17-\354\235\264\352\260\200\354\235\200-chap10.-\354\234\240\353\213\211\354\212\244\354\235\230-\354\227\255\354\202\254\354\231\200-\354\225\204\355\202\244\355\205\215\354\262\230.md"
new file mode 100644
index 0000000..838e314
--- /dev/null
+++ "b/_posts/processinalC/chap10.-\354\234\240\353\213\211\354\212\244\354\235\230-\354\227\255\354\202\254\354\231\200-\354\225\204\355\202\244\355\205\215\354\262\230/2023-12-17-\354\235\264\352\260\200\354\235\200-chap10.-\354\234\240\353\213\211\354\212\244\354\235\230-\354\227\255\354\202\254\354\231\200-\354\225\204\355\202\244\355\205\215\354\262\230.md"
@@ -0,0 +1,242 @@
+---
+title: "🐢 chap10. 유닉스의 역사와 아키텍처"
+author: gani0325
+date: 2023-12-17 20:00:00 +09:00
+categories: [전문가를 위한 C, "chap10. 유닉스의 역사와 아키텍처"]
+tags: [전문가를 위한 C, C언어, 9주차, 이가은]
+render_with_liquid: false
+math: true
+---
+
+<h2> ⭐ 10.1 유닉스의 역사 </h2>
+
+✅ **10.1.1 멀틱스와 유닉스**
+
+1. 유닉스 이전에 벨 연구소가 주도한 **멀틱스 OS**
+2. 유닉스의 선구자였던 켐 톰슨이나 데니스 리치는 여러 이유로 멀틱스를 포기
+3. 벨 연구소에서 고안한 더 단순하고 더 효율적인 운영체제 **유닉스**
+
+✅ **멀티스와 유닉스 차이점과 유사점**
+
+- 멀틱스와 유닉스 모두 내부 구조로 '**양파처럼 여러 겹으로 구성된 링 모양의 아키텍처**' 둘 다 아키텍처 내에 거의 같은 구조의 링이 있는데, 특히 커널 링과 셸 링이 이에 해당
+- 멀틱스는 작동하기 위해 비싼 자원과 머신이 필요
+- 멀틱스는 설계가 복잡
+
+—> 2000년 10월 30일에 마지막으로 멀틱스를 쓰던 컴퓨터가 종료.
+
+- 멀틱스가 제안한 아이디어와 혁신을 단순화한 결과 → **유닉스**
+
+✅ **10.1.2 BCPL과 B**
+
+1. **BCPL**은 마틴 리처드Martin Richards가 컴파일러를 작성할 목적으로 만든 프로그래밍 언어
+2. 어셈블리어가 아닌 더 **고급 프로그래밍 언어**를 사용해 운영체제를 성공적으로 작성할 수 있음을 확인한 벨 연구소
+3. 멀틱스는 유닉스를 개발하는 과정에서 다른 언어를 사용한다는 아이디어의 중심
+4. 벨 연구소의 켄 톰슨과 데니스 리치는 BCPL을 사용하려고 했지만, DEC PDP-7 과 같은 미니 컴퓨터에서 BCPL을 사용하려면 언어의 몇몇 부분을 수정해야 했다.
+5. 이러한 이유로 **B 언어 탄생**
+6. B는 시스템 프로그래밍 언어 관점에서 단점이 존재
+
+   - **B는 메모리에서만 워드를 사용할 수 있었습니다.**
+
+   모든 운영체제는 워드의 관점에서 수행되어야 했습니다. 당시에는 바이트로 작동하는 프로그래밍 언어란 꿈만 같은 것이었습니다. 그 당시 사용할 수 있었던 하드웨어는 워드 기반 체계 scheme로 메모리를 다뤘기 때문입니다.
+
+   - **B는 자료형이 없었습니다**.
+
+   더 정확하게 말하자면 B는 단일 자료형 언어였습니다.(ypeless 언어) 모든 변수는 워드자료형이었습니다. 그러므로 만약 20개의 문자(끝에 null 문자가 더해져 21개)를 갖는 문자열이 있다면, 이를 워드로만 나누어서 하나 이상의 변수에 담아야 했습니다. 워드가 4바이트인 경우, 21개 문자로 된 문자열을 저장하려면 변수 6개가 필요합니다.
+
+   - **자료형이 없다는 것은 문자열 조작 알고리듬 같은 멀티바이트multibyte 지향 알고리듬이 B에서 효율적으로 작성될 수 없음을 의미합니다**.
+
+   B는 바이트가 아닌 워드로 메모리를 사용했기 때문입니다. 정수나 문자열 같은 멀티바이트 자료형을 다루기에 워드는 효율적으로 사용될 수 없었습니다.
+
+   - **B는 부동소수점 연산을 지원하지 않았습니다.**
+
+   당시 점점 더 많은 새로운 하드웨어에서 부동소수점 연산을 이용할 수 있었지만, B 언어에서는 이를 지원하지 않았습니다.
+
+   - **프로그램이 메모리에서 특정 바이트 또는 한 바이트 범위에 접근하려고 할 때, 해당하는 워드 인덱스를 계산하려면 더 많이 연산해야 했습니다.**
+
+   바이트 기반으로 메모리를 다룰 수 있는 PDP-1과 같은 머신을 이용할 수 있었지만, B는 메모리의 바이트를 다루기에 비효율적임이 드러났습니다. 이는 B 포인터에서 더 명확해졌는데, 이 포인터는 바이트가 아니라 메모리의 워드만을 다룰 수 있었기 때문입니다.
+
+   이러한 이유로 **NB (New B)** 언어를 개발할 때까지 B 언어는 계속 수정해야 했습니다
+
+7. 나중에 B 언어로부터 구조체가 유래되었다. 이러한 B에서는 구조체의 자료형이 없었지만, C에서는 자료형이 존재
+
+8. 마침내 1973년에 유닉스의 네 번째 버전은 (여전히 어셈블리 코드 존재) **C**를 이용해 개발
+
+<h2> ⭐ 10.2 유닉스 아키텍처 </h2>
+
+✅ **10.2 유닉스 아키텍쳐**
+
+멀틱스와 유닉스는 모두 비슷한 아키텍처를 도입하려 했습니다. 하지만 이 둘은 상당히 다른 운명에 처합니다. 멀틱스는 세기말에 잊히기 시작한 반면, 유닉스 및 BSD와 같은 유닉스 기반의 운영체제는 그 이후로도 성장하고 있습니다.
+
+유닉스 철학 → 간단히 **유닉스 설계가 기반으로 하는 고수준의 요구 사항을 모은 집합**
+
+✅ **10.2.1 유닉스 철학**
+
+- **유닉스는 일반적인 최종 사용자end user가 아닌 개발자를 위해 설계 및 개발되었습니다.** 그러므로 사용자 인터페이스나 사용자 경험에서 요구하는 여러 고려 사항은 유닉스 아키텍처에 해당하지 않습니다.
+- **유닉스 시스템은 작고 단순한 여러 프로그램으로 구성됩니다.** 이들 프로그램 각각은 작고 단순한 일을 수행하려고 설계되었습니다. ls. mkdir. ifconfig, grep, sed 같이 작고 단순한 프로그램의 사례가 많습니다.
+- **복잡한 일은 작고 단순한 프로그램을 연쇄적으로 실행해서 수행할 수 있습니다.** 크고 복잡한 일에는 본 질적으로 하나 이상의 프로그램이 함께 포함되어야 하며, 각 프로그램은 임무를 달성하려면 여러 번 실 행되어야 한다는 의미입니다. 처음부터 프로그램을 작성하는 대신 셸 스크립트를 사용하는 것이 그 좋은 사례입니다. 참고로 셸 스크립트는 유닉스 시스템 간에 빈번하게 이식될 수 있으며, 유닉스는 개발자가 크고 복잡한 프로그램을 작고 단순한 프로그램으로 나누도록 장려합니다.
+- **각각의 작고 단순한 프로그램은 출력 결과를 다른 프로그램의 입력으로 전달할 수 있어야 하며, 이 체인 은 계속 이어져야 합니다.** 이러한 방식으로 복잡한 일을 수행할 능력이 있는 체인으로 작은 프로그램을 사용할 수 있습니다. 이 체인에서 각 프로그램은 이전 프로그램의 출력을 받고, 로직에 따라 형태를 바꾸고 체인의 다음 프로그램에 이를 전달하는 트랜스포머 transformer로 간주할 수 있습니다. 특히 유닉스 명령어 사이에 있는 수직 막대 파이프인 ls -l | grep a.out과 같은 것이 좋은 예시입니다.
+- **유닉스는 매우 문자 지향적입니다.** 모든 환경 설정은 텍스트 파일로 되어 있으며, 문자로 된 명령어를 가집니다. 셸 스크립트 또한 다른 유닉스 셸 프로그램을 실행하는 알고리듬을 작성하는 단순한 문법을 사용하는 텍스트 파일입니다.
+- **유닉스는 완벽함보다 간결함을 선택하도록 제안합니다.** 예를 들어 대부분의 경우에 단순한 해결책이 효과적이라면 미미한 정도로 조금 더 잘 작동하는 복잡한 해결책을 설계하지 않아야 합니다.
+  ・**어떤 유닉스 호환 운영체제에 대해 작성된 프로그램은 다른 유닉스 시스템에서도 쉽게 사용할 수 있어야 합니다.** 이는 주로 다양한 유닉스 호환 시스템에서 빌드 및 실행 가능한 단일 코드베이스를 갖춤으로써 충족됩니다.
+
+✅ **10.2.2 유닉스 링**
+
+![30.png](/assets/img/gani0325/30.png)
+
+링 모델은 **유닉스의 전반적인 아키텍처**를 묘사할 수 있습니다.
+**링 각각 은 내부의 링을 감싸는 래퍼**로 기능합니다.
+
+1. 링 모델의 핵에는 **하드웨어**가 있습니다.
+
+운영체제의 주요 임무는 사용자가 하드웨어와 상호작용해 하드웨어를 사용할 수 있게 하는 것입니다.
+즉, **하드웨어에 접근하려는 프로그램이 하드웨어를 사용할 수 있도록 하는 것**이 유닉스의 주요 목표입니다.
+
+2. 하드웨어를 둘러싼 링은 **커널 kernel** 입니다.
+
+- 커널은 운영체제에서 가장 중요한 부분입니다.
+  하드웨어와 가장 가까운 층이고, 하드웨어에 직접 부착된 기능을 드러내는 래퍼 wrapper의 역할을 하기 때문입니다.
+- 이렇게 직접적으로 접근할 수 있으므로, **커널은 시스템의 전체 자원을 이용할 수 있는 가장 높은 권한**을 갖습니다.
+- 새로운 유닉스 계열 운영체제를 작성할 때는 커널을 작성하는 데 가장 큰 노력이 필요합니다.
+- 커널 링이 다른 링보다 두껍게 그려져 있습니다. 유닉스 커널 내부에는 많은 다양한 유닛이 존재하며, 유닛 각각은 유닉스 생태계에서 필수적인 역할을 합니다.
+
+3. 다음 링은 **셸shell** 입니다.
+
+- 사용자 **응용프로그램이 커널과 상호작용**해 커널의 여러 서비스를 사용할 수 있도록 하는 것이 커널 주변의 셸입니다.
+- 셸 링은 유닉스 철학에 따른 대부분의 요구 사항을 주로 **단독으로 제공**
+- 셸 링은 여러 작은 프로그램으로 구성됩니다. 이들 프로그램은 사용자나 응용프로그램이 커널의 서비스를 사용할 수 있도록 하는 도구 모음을 형성합니다. 또한 셸 링은 라이브러리 모음도 포함하는데, 이 라이브러리는 모두 C로 작성되었습니다.
+- 단일 유닉스 규격 simple Unix Specification (SUS)에 있는 라이브러리를 기반으로, 셸 링은 개발자를 위해 **표준 및 간결하게 정의된 인터페이스를 반드시 노출**해야 합니다.
+
+4. 마지막으로 가장 바깥쪽 링인 **사용자 응용프로그램**
+
+- 유닉스 시스템에서 사용하기 위해 작성된 실제 모든 응용프로그램으로 구성됩니다.
+- 여기에는 데이터베이스 서비스, 웹 서비스, 메일 서 비스, 웹 브라우저, 워크시트 프로그램, 워드 편집 프로그램 등이 있습니다.
+- 이러한 응용프로그램은 임무를 완수하기 위해, 곧 다룰 **시스템 호출system call**을 통해서 커널에직접 접근하기보다는 셸 링이 제공하는 API와 도구를 사용해야 합니다. 유닉스 철학에 있는 **이식성의 원리** 때문입니다.
+- 셸 링만 사용해야 한다는 제약은 이러한 응용프로그램이 유닉스 호환 운영체제가 아닌 다양한 유닉스 계열 시스템에서 호환할 수 있도록 합니다.
+- 유닉스 링 모델에 대한 일반적인 주제 중에는 **바깥 링이 서비스를 사용할 수 있도록 내부 링이 인터페이스를 제공해야 한다**는 것이 있습니다. 사실 링 사이의 인터페이스는 링 그 자체보다 더 중요합니다.
+
+<h2> ⭐ 10.3 사용자 응용프로그램에 대한 셸 인터페이스 </h2>
+
+**인간 사용자**는 유닉스 시스템의 기능을 사용하기 위해 터미널이나 웹 브라우저 같은 특정 GUI 프로그램을 사용합니다.
+
+- **터미널과 GUI 프로그램 = 사용자 응용프로그램 = 응용프로그램 = 프로그램**
+- 이들은 셸 링을 통해 하드웨어를 사용할 수 있도록 합니다. 셸링이 제공하는 API를 통해 대부분의 유닉스 프로그램이 일반적으로 사용하는 하드웨어로는 메모리, CPU, 네트워크 어댑터, 하드디스크 드라이브가 있습니다.
+- **유닉스를 위해 C로 개발된 다양한 프로그램이 존재. 이들의 공통점은?** 이들 프로그램의 코드는 약간만 변형하면 대부분의 유닉스 및 유닉스 계열 운영체제에서 이식 가능
+- **어떻게 가능한가?**
+  답은 간단합니다. 모든 유닉스 시스템은 셸 링에서 같은 응용프로그램 프로그래밍 인터페이스Application Programming Interface (API)를 노출합니다. 노출된 표준 인터페이스만을 사용하는 C 소스 코드는 모든 유닉스 시스템에서 빌드 및 실행할 수 있습니다.
+- **그렇다면 API를 노출한다는 의미는?**
+  API는 이전에 설명한 대로, 일련의 선언을 포함하는 헤더 파일의 묶음입니다. 이 헤더와 그 안에 있는 선언된 함수는 모든 유닉스 시스템에서 같습니다. 하지만 이 함수의 구현, 즉 각각의 유닉스 호환 시스템을 위해 작성된 정적, 동적 라이브러리는 서로 고유하고 다를 수 있습니다.
+
+✅ **유닉스 호환시스템이란?**
+우리는 유닉스를 운영체제가 아닌 **표준**으로 봅니다. 유닉스 표준과 완전히 호환 가능하도록 만들어진 시스템이 존재하며, BSD 유닉스와 같은 이러한 시스템을 → 유닉스 호환 시스템
+
+✅ **유닉스 계열시스템이란?**
+
+유닉스 표준을 부분적으로 따르는 시스템은 유닉스 계열 시스템이라고 하는데, 리눅스가 이에 해당
+
+셸 링이 노출하는 여러 종류의 API가 있습니다. 이들 중 몇 가지는 의무 사항이고 나머지는 선택 사항입니다. 다음은 SUS V4에 있는 API 목록입니다.
+
+- **시스템 인터페이스**: 모든 C 프로그램에서 사용할 수 있는 모든 함수의 목록입니다. SUS 4에는 유닉스시스템에서 구현되어야 하는 1.191개의 함수가 있습니다. 이 테이블은 C의 특정 버전에서 특정 함수가 의무 또는 선택이라 명시합니다. 참고로 우리가 관심 있는 버전은 C99입니다.
+- **헤더 인터페이스**: SUS v4와 호환 가능한 유닉스 시스템에서 사용할 수 있는 헤더 파일 목록입니다. 이 SUS 버전에서는 모든 C 프로그램에 접근할 수 있는 82개의 헤더 파일이 있습니다. 이 리스트를 살펴 보면 stdio.h, stdlib.h, math.h, string.h와 같은 유명한 헤더 파일이 많음을 알 수 있습니다.
+- **유틸리티 인터페이스**: SUS v4와 호환되는 유닉스 시스템에서 사용할 수 있는 유틸리티 프로그램 또는 커맨드 라인 프로그램의 목록입니다. 테이블을 살펴보면, 여러분에게 친숙할 많은 명령어가 보입 니다. mkdir. ls, cp. df, bc 그리고 더 많은 명령어가 여기에 있으며 160개의 유틸리티 프로그램로 구성됩니다.
+- **스크립팅 인터페이스**: 셸 스크립트를 작성할 때 사용되는 언어입니다. 주로 유틸리티 프로그램을 사용하 는 자동화된 임무를 작성하는 데 사용합니다. 일반적으로 스크립팅 인터페이스는 **셸 스크립팅 언어 scripting language** 또는 **셸 명령어 shell command language**라고 합니다.
+- **XCURSES 인터페이스**: XCURSES는 미니멀한 텍스트 기반의 GUI에서 C 프로그램과 사용자가 상호작용할 수 있도록 하는 일련의 인터페이스입니다. 다음 스크린에서 XCURSES에 대한 구현인 ncurses를 사용해 작성된 GUI에 대한 예를 볼 수 있습니다. SUS V4에는 3개의 헤더 안에 379개 의 함수와 4개의 유틸리티 프로그램이 있습니다. .
+- SUS는 **시스템에서 헤더를 어디에서 사용할 수 있고 어디에 있는지를 설명**할 뿐입니다
+- **C 표준 라이브러리** 또는 **libc 시스템 인터페이스** + **헤더 인터페이스**를 + 각 유닉스 버전 Unix flavor (혹은 유닉스 구현)마다 다른, 제공받은 **함수**의 구현들의 합
+- **이식 가능한 운영체제 인터페이스 Portable Operating System Interface (POSIX)**. 리눅스 탄생 후 여러 유닉스계열 운영체제 개발되었는데. 이는 SUS 표준의 부분집합에 특정 이름을 부여하는 토대가 되었습니다. POSIX는 유닉스 계열 시스템이 따르는 SUS 표준의 **부분집합**POSIX는 유닉스 표준이 더 광범위한 운영체제에 적용 가능하도록 합니다.
+- SUS와 POSIX 표준은 모두 인터페이스에 대한 규칙입니다.
+- 각 유닉스 시스템은 POSIX 또는 SUS 구현에 대한 자체적인 구현이 있습니다.
+- 이러한 구현은 셸 링에 속하는 libc 라이브러리에 위치합니다.
+- 다시 말해, 유닉스 시스템에서 셸 링은 표준 방식으로 제공해야 하는 libc 구현을 포함합니다.
+- 그에 따라 셸 링은 요청을 전달해 커널 링이 처리하도록 합니다.
+
+<h2> ⭐ 10.4 셸 링에 대한 커널 인터페이스  </h2>
+
+정의된 인터페이스를 제공한다고 설명했습니다. 셸 링에서 특정 로직을 불러오는 방식에는 주로 두 가지가 있습니다.
+
+- libc 또는 셸 유틸리티 프로그램을 통하는 방식입니다.
+
+셸 루틴을 실행하기 위해 사용자 응용프로그램은 libc 라이브러리와 연결되거나 또는 시스템에서 사용 가능한 기존의 유틸리티 프로그램을 실행할 수 있어야 합니다.
+
+참고로 기존 유틸리티 프로그램은 자체적으로 libc 라이브러리를 사용합니다. 그러므로 모든 셸 루틴을 libc 라이브러리에서 찾을 수 있다고 일반화할 수 있습니다.
+
+- FreeBSD는 BSD 유닉스에서 파생된 유닉스계열 운영체제입니다.
+
+다음 예제로 시작해봅시다. [예제 10-1]은 1초를 기다리기만 하는 간단한 프로그램입니다. 마
+찬가지로 이 프로그램은 응용프로그램 링에 있을 것으로 여겨집니다. 비록 매우 단순한 프로그
+램이지만, 사용자 응용프로그램이라는 의미입니다.
+
+**셸 박스 10-1** [예제 10-1]이 불러온 시스템 호출을 추적하기 위해 truss를 사용하는 [예제 10-1]을 빌드하고 실행하기
+
+```c
+// File name: ExtremeC_examples_chapter10_1.c
+// Description: Simple sleep
+
+#include <unistd.h>
+
+int main(int argc, char** argv) {
+	//시스탬 호출
+  sleep(1);
+  return 0;
+}
+~
+```
+
+[박스 10-1]에서 볼 수 있듯, truss라는 유틸리티 프로그램을 사용했습니다.
+
+- nanosleep은 시스템 호출입니다.
+  - 시스템 호출은 time.h에 정의된 셸 링에서 nanosleep과 clock_nanosleep 함수를 호출해 접근할 수 있습니다. 참고로 여기서는 unitsd.h의 sleep 함수를 사용했습니다.
+  - 이러한 함수를 호출하려면 링커에-lc 옵션을 전달해 libc에 대해 실행 가능한 파일을 링크해야 합니다. 이는 FreeBSD만 해당될 수 있습니다.
+
+<h2> ⭐ 10.5 커널 </h2>
+
+- 커널의 개념 : 컴퓨터가 켜진 후부터 메모리에 상주하는 운영체제의 실행 코드 모음으로, 하드웨어 및 사용자 프로그램 관리자 역할을 수행
+
+- **모놀리식 커널**
+
+  - 하드웨어 기능을 제공하기 위해 여러 유닉스 링 사이에서 이루어지는 함수 호출과 시스템 호출
+  - 모놀리식 커널에만 해당
+
+- **커널 프로세스**
+
+  - 첫 번째로 로드 및 실행됩니다. 하지만 사용자 프로세스가 스폰되기 전에 커널 프로세스가 로드되고 실행되어야 합니다.
+  - 커널 프로세스는 하나여야 합니다. 하지만 동시에 작업 중인 여러 개의 사용자 프로세스가 있을 수 있습니다.
+  - 커널 프로세스는 부트로더boot loader에 의해 메인 메모리로 커널 이미지를 복제해 생성됩니다.
+  - 하지만 사용자 프로세스는 exec이나 fork 시스템 호출을 이용해 생성됩니다. 이러한 시스템 호출은 대부분의유닉스 시스템에 존재합니다.
+  - **커널 프로세스**는 시스템 호출을 다루고 실행합니다. 하지만 사용자 프로세스는 시스템 호출을 불러와 커널 프로세스가 시스템을 호출하기를 기다립니다.
+  - 커널 프로세스는 물리 메모리 및 권한 수준이 높은 모드 privileged mode에 있는 모든 연결된 하드웨어를 봅니다.
+  - 사용자 프로세스는 가상 메모리를 봅니다. 가상 메모리는 물리 메모리의 일부에 연결된 것으로 물리 메모리 레이아웃에 관해서는 아무것도 알지 못합니다. 마찬가지로 사용자 프로세스는 리소스와 하드웨어에 대한 접근을 통제하고 감독합니다. 사용자 프로세스는 운영체제가 시뮬레이션한 샌드박스 안에서 실행되는 것이라고 할 수 있습니다. 이는 사용자 프로세스가 다른 사용자 프로세스의 메모리를 볼 수 없음을 나타냅니다.
+
+- **운영체제 런타임**
+
+  - 커널 프로세스 모드, 사용자 프로세스 모드
+  - 전자의 실행 모드는 커널 랜드 또는 커널 공간이라고 합니다. 후자는 유저 랜드 또는 사용자 공간이라고 합니다.
+  - 사용자 프로세스가 시스템 호출을 불러오는 것은 두 랜드를 함께 가져오는 방식입니다. 기본적으로 커널 공간과 사용자 공간을 서로 분리해야 했으므로 시스템 호출이 고안되었습니다.
+  - 커널 공간은 시스템 자원에 접근할 수 있는 가장 권한이 높은 것이고, 사용자 공간은 가장 권한이 낮으며 감독받는 접근 권한을 갖습니다.
+  - 일반적인 유닉스 커널에 대한 내부 구조는 커널이 수행하는 임무에 따라 구별할 수 있습니다.
+  - 사실 하드웨어를 관리하는 일은 커널이 수행하는 여러 임무 중 하나입니다.
+
+- **유닉스 커널이 갖는 권한 목록**
+
+  - 프로세스관리: 사용자 프로세스는 시스템 호출을 통해 커널이 생성합니다. 새로운 프로세스에 대한 모리 할당과 그에 대한 명령어 로딩은 모든 작업 중에서 프로세스를 실행하기 전 반드시 수행해야 하는 작업입니다.
+  - 프로세스 간 통신 Inter-Process Communication (IPC) : 동일한 머신에 있는 사용자 프로세스는 그들 간 데이터를 교환하는 서로 다른 메서드를 사용할 수 있습니다.
+  - 이러한 메서드에는 공유 메모리, 파이프, 유닉스 도메인 소켓이 있습니다. 커널이 이 메서드를 사용할 수 있도록 해야 하며, 메서드 중 일부는 커널이 데이터 교환을 통제해야 합니다.
+  - 스케줄링: 유닉스는 항상 다중 작업(멀티태스킹) 운영체제로 알려졌습니다. 커널은 CPU 코어에 대한 접근을 관리하며 이 접근에 대한 균형을 유지하려고 합니다.
+  - 커널 임무 : 메모리 관리(주요 임무), 프로세스 할당, 메서드 공유(파이프 제공), 다중 작업, 스케줄링, 등
+
+- **멀티스레딩, 멀티프로세싱**
+
+  - 시스템 시작: 일단 커널 이미지가 메인 메모리에 로드되고 커널 프로세스가 시작되면, 커널은 사용자 스페이스를 초기화해야 합니다. 이는 주로 프로세스 식별자 process identifier (PID) 1로 첫 번째 사용자 프로세스를 생성함으로써 수행됩니다. 리눅스와 같은 몇몇 유닉스 시스템에서는 이 프로세스를 init이라고 합니다. 이 프로세스가 시작된 뒤에 다른 서비스와 데몬 daemon이 시작됩니다.
+  - 장치 관리 : CPU와 메모리 외에도 커널은 모든 커널에 대해서 추상화를 통해 하드웨어를 관리할 수 있어야 합니다. 장치는 유닉스 시스템에 연결된 실제 또는 가상의 하드웨어입니다. 일반적인 유닉스 시스템은 /dev 경로를 사용해 연결된 장치 파일을 저장합니다. 연결된 모든 하드디스크 드라이브, 네트워크 어댑터, USB 장치 등은 /dev 경로에 있는 파일과 연결됩니다. 이러한 장치 파일은 사용자 프로세스가해당 장치와 통신할 때 사용할 수 있습니다.
+
+- 커널에는 이용 가능한 물리 메모리를 관리하는 메모리 관리 유닛 Memory Management unit (MMU)과 같은 다양한 유닛이 있습니다.
+  - 프로세스 관리 유닛은 사용자 공간에 프로세스를 만들며 이에 대해 리소스를 할당합니다. 또한 프로세스 관리 유닛은 프로세스가 IPC를 사용할 수 있도록 합니다 .
+  - 파일 시스템 유닛은 커널의 필수적인 부분으로, 블록과 문자 장치에 대한 추상화이며 프로세스와 커널 자신이 같은 공유 파일 계층을 사용할 수 있도록 합니다.
+
+![31.png](/assets/img/gani0325/31.png)
+
+<h2> ⭐ 10.6 하드웨어 </h2>
+
+- CPU와 메인 메모리는 유닉스 시스템에 연결된 필수 장치입니다.
+- 주변 장치
+  - 하드디스크 드라이브, 네트워크 어댑터, 마우스, 모니터, 그래픽 카드, 와이파이 어댑터와 같은 나머지 모든 하드웨어는 주변 장치입니다. -유닉스 커널은 CPU와 물리 메모리를 완벽하게 숨깁니다. 커널만이 이를 직접 관리하며, 사용자 공간에서는 접근이 허용되지 않습니다. 유닉스 커널에 있는 메모리 관리 및 스케줄러 유닛은 물리 메모리와 CPU를 각각 관리합니다.
+- 유닉스 시스템에 연결된 다른 주변 장치는 이에 해당하지 않습니다. 주변 장치는 장치 파일이라는 메커니즘을 통해 노출됩니다.
diff --git a/assets/img/gani0325/30.png b/assets/img/gani0325/30.png
new file mode 100644
index 0000000..ffe291f
Binary files /dev/null and b/assets/img/gani0325/30.png differ
diff --git a/assets/img/gani0325/31.png b/assets/img/gani0325/31.png
new file mode 100644
index 0000000..fe0136f
Binary files /dev/null and b/assets/img/gani0325/31.png differ