1. 커널 (Kernel) 이란?

커널은 운영체제(OS)의 주요 구성 요소이며 컴퓨터 하드웨어와 프로세스를 잇는 핵심 인터페이스이다.

커널이라는 이름은 단단한 껍질 안의 씨앗처럼 OS 내에 위치하고 전화기, 노트북, 서버 또는 컴퓨터 유형에 관계없이 하드웨어의 모든 주요 기능을 제어하기 때문에 붙은 이름이다.

 

 

2. 커널의 기능

1) 메모리 관리: 메모리가 어디에서 무엇을 저장하는 데 얼마나 사용되는지를 추적합니다.

2) 프로세스 관리: 어느 프로세스가 중앙 처리 장치(CPU)를 언제 얼마나 오랫동안 사용할지를 결정합니다.

3) 장치 드라이버: 하드웨어와 프로세스 사이에서 중재자/인터프리터의 역할을 수행합니다.

4) 시스템 호출 및 보안: 프로세스의 서비스 요청을 수신합니다.

 

 

3. 이중 실행 모드 (Kernel mode vs User mode)

Kernel mode와 User mode에 대해 살펴보기 전에, 이를 나눈 근본적인 이유가 상당히 중요하다.

응용 프로그램이 시스템 자원에 직접 접근하게 되면 심각한 오류들을 유발할 수 있기 때문에, 각 응용 프로그램이 시스템 자원에 직접 접근하지 못하도록 하기 위해서 나누어 놓았다. 따라서, 자원에 대한 접근 권한은 커널에게만 부여하여, 자원에 대한 접근이 필요한 시점에는 System call을 통해서 간접적으로 실행하도록 하였다. 결국 자원에 대한 접근은 커널을 통해서만 접근할 수 있는 것이다.

 

1. 커널 모드 (Kernel mode / SuperVisor mode)

커널 모드에서 운영체제는 모든 하드웨어에 대한 완전한 접근이 가능하며, 기계가 실행할 수 있는 어떤 명령도 실행할 수 있다. 즉, Kernel mode는 운영체제가 CPU의 제어권을 가지고 명령을 수행하는 모드로 일반 명령과 특권 명령 모두 수행할 수 있다. 또한 모든 주소 공간에 접근이 가능하다.

 

2. 유저 모드 (User mode)

유저 모드 기계 명령 중 일부만을 실행할 수 있는 모드로, 특별히 기계의 제어에 영향을 미치거나 I/O를 하는 명령들은 사용자 모드에서 실행할 수 없다. 즉, User mode는 일반 사용자 프로그램이 CPU 제어권을 가지고 명령을 수행하는 모드이기 때문에 일반 명령만을 수행할 수 있다. 또한 사용자 주소 공간만 접근이 가능하다.

 

운영체제 구조

 

4. 일반/특권 명령

CPU가 수행하는 명령에는 2가지 명령이 있는데, 명령을 다음과 같이 구분하여 부적절한 사용을 막는다.

 

일반 명령은 메모리에서 자료를 읽어와 CPU에서 계산하고 결과를 메모리에 쓰는 등의 명령이고, 모든 프로그램이 수행할 수 있는 명령이다. 따라서 사용자 응용 프로그램은 특권 명령을 사용하지 못합니다.

 

특권 명령은 프로세스 제어, 파일 조작, 장치(I/O, 타이머 등) 조작, 정보 유지 보수, 통신, 보호 등의 명령으로, 항상 운영체제에서만 수행할 수 있으며, 특권 명령을 사용하고 싶을 때 사용하는 것이 바로 '시스템 콜'이며 OS에게 특권 명령을 대신 실행해달라고 요청하는 것입니다.

 

5. 논리 주소 공간

1. 사용자 주소 공간 (User space)

  • 각 응용 프로그램이 나누어 적재되고 사용되는 공간

2. 커널 주소 공간 (Kernel space)

  • 커널에 의해 배타적으로 사용 - 커널 코드, 커널 데이터, 디바이스 드라이버 등

 

커널

 

6. 커널과 관련된 Issue

1. 커널은 스스로 실행되는 프로세스인가?

  • X, 시스템 호출을 통해 호출되는 단순 함수/데이터의 집합

2. 커널은 실행 중이다?

  • X, 시스템 호출/인터럽트를 통해 커널 코드/ISR이 실행되고 있을 뿐이다. (능동적인 주체 x, 수동적인 대상 o)

3. 커널은 스택이나 힙을 갖는가?

  • X, 각 프로세스/스레드가 스택/힙 소유
    • app이 커널 코드 실행 시, 커널 공간에 커널 코드 실행을 위한 스택 생성, 복귀 시 해제
  • 커널은 하나의 프로세스가 아니므로 그 자신만의 스택/힙을 갖지 않는다. 사용자 프로그램이 시스템 호출을 통해 간접적으로 커널 함수를 호출하게 되면, 현재 커널 코드의 실행을 위해 커널 영역에 stack이 임시로 생성이 될 수는 있다. 하지만 이는 커널이 관리하는 것이 아니라, 사용자 프로그램의 요청을 처리하기 위해 임시로 만들어진 stack/heap 에 불과하다. 따라서 시스템 호출을 마무리하고 복귀하면 없어진다.

 

 

Reference

[커널] https://www.redhat.com/ko/topics/linux/what-is-the-linux-kernel

[Modern Operating Systems 3rd]

 

'CS > 운영체제 (OS)' 카테고리의 다른 글

8. IPC (Inter-Process Communication)  (0) 2021.08.11
7. 프로세스 vs 스레드  (0) 2021.08.11
4. 프로세스의 주소 공간  (1) 2021.08.08
3. 인터럽트 (Interrupt)  (1) 2021.08.08
1. 운영체제 (OS) & 부팅과정  (1) 2021.08.06

개요

그동안 학교에서 배웠던 내용 + 전공책을 뒤져가며 공부했던 내용 + 취준 하면서 복습했던 내용들을 정리하는 목적으로 작성하였습니다.

 

1. 운영체제(OS) 란?

시스템의 자원과 동작을 관리하는 소프트웨어다.

  • 자원? CPU, memory, file, I/O

 

 

2. 운영체제의 기능

'커널 모드에서 실행하는 소프트웨어'로 크게 2가지 기능을 제공

  1. 하드웨어와 응용 프로그램의 매개로 아름답고 일관된 인터페이스로 제공한다. (사용자 관점)
  2. 하드웨어의 자원들을 공정하게 할당 및 관리한다. (시스템 관점)

 

 

3. 부팅 시 운영체제 실행 과정

1. BIOS(Basic Input Output System)

제일 먼저 CPU가 ON 되고, CPU는 ROM(비휘발성 메모리)에 있는 BIOS(Basic Input Output System) 데이터를 읽어온다.

 

2. POST(Power on self test)

BIOS는 POST(Power on self test)를 진행하여 하드웨어의 정상적인 작동을 검사한다.

부팅: 1.BIOS & 2.POST

3. 부트스트랩(Bootstrap)

POST에 이상이 없으면 BIOS는 부트스트랩을 실행하여 부팅 정보를 메모리로 읽어 온다.

  • 부트스트랩 : Disk의 MBR에 저장된 부팅 정보를 RAM(메모리)으로 읽어온다.
  • MBR(Master Boot Record): Disk의 첫 번째 섹터

4. 부트로더(Bootloader)

"운영체제(Boot)를 메모리로 읽어오는 역할(loader)"

부트로더는 Disk에 있는 운영체제(OS) 코드를 메모리로 읽어 온다. 즉, 앞에서 읽어온 부팅 정보는 부트로더(Bootloader)이다. 운영체제는 메모리에 상주하지 않지만 커널은 메모리에 상주한다.

부팅: 3.부트스츠랩 & 4.부트로더

5. 운영체제(OS) 실행

읽어 온 운영체제 명령에 의해 CPU는 첫 프로세스(Demon)를 즉시 실행한다.

이후, 인터럽트가 발생하면 CPU는 각종 작업을 처리한다.

부팅: 5. 운영체제 읽어옴

 

 

 

Reference

[부팅 과정] https://neos518.tistory.com/113

[Modern Operating Systems 3rd] 

'CS > 운영체제 (OS)' 카테고리의 다른 글

8. IPC (Inter-Process Communication)  (0) 2021.08.11
7. 프로세스 vs 스레드  (0) 2021.08.11
4. 프로세스의 주소 공간  (1) 2021.08.08
3. 인터럽트 (Interrupt)  (1) 2021.08.08
2. 커널 (Kernel)  (0) 2021.08.06

📥 Github 설치하기

1. Github 기본 명령어

1) local repository용

  • git init : 새로운 저장소 만들기
  • git clone [원격 저장소 URL] : 저장소의 모든 파일들을 가져오기만 함
    • git clone -b [브랜치명] [원격 저장소 URL]: 특정 브랜치를 clone
  • git add [추가할 파일명] : 커밋할 파일을 stage(커밋하기 위한 준비 상태에 돌입) 시켜줍니다
    • -update : 추적하고 있는 파일만 add
  • git rm [삭제할 파일명] : 제거 관련 명령어
    • -cached : 해당 파일을 working directory 상태로 되돌림
      (Git 저장소에서만 삭제하고 실제 파일은 남겨두고 싶은 경우)
  • git commit -m "[커밋 메시지]" : commit 메시지와 함께 commit
  • git commit --ammend : commit 메세지 변경
  • git status : git 상태 확인
  • git log : commit 목록 확인

2) local repository ↔ remote repository

  • git remote : local repository에 연결된 remote repository를 확인
  • git remote add [별칭] [remote repository URL 주소] : 원격 저장소 등록
  • git remote show [원격 저장소명] : 원격 저장소 정보
  • git push [원격 저장소명] [원격 branch명] : branch 명에는 master 혹은 develop 등의 본인이 만든 branch의 이름을 넣어 주세요
  • git push [원격 저장소명] [원격 branch명] : branch 명에는 master 혹은 develop 등의 본인이 만든 branch의 이름을 넣어 주세요
  • git pull [원격 저장소명] [원격 branch명]: local repository와 비교하여 병합을 하고, local repository에 저장( add )까지 수행
    • git pull = git fetch + git merge

3) master ↔ branch

  • git branch : 브랜치의 목록과 현재 사용하고 있는 브랜치를 확인
  • git branch [branch] : 브랜치 생성
    • -r [branch] : remote repository 브랜치 목록 확인
    • -a [branch] : local / remote repository 모두의 브랜치 목록 확인
    • -D [branch] : local repository 브랜치 삭제
  • git checkout [branch] : 브랜치를 이동
  • git checkout -b [branch] : 브랜치 생성 후, 그 브랜치로 이동
  • git fetch : local repository에서 remote repository와 동기화하는 역할(업데이트)
  • git merge [브랜치] : 현재 checkout 하고 있는 branch로 [branch]에서 병합
  • git checkout master git merge develop # develop --merge-> master

branch를 merge 할 때는 같은 파일을 수정할 경우 생길 수 있는 충돌 발생을 항상 주의해야 합니다.

2. Github 취소 명령어

1) git add 취소하기

git reset HEAD [파일명] : git add 한 [파일] 취소, 수정된 워킹 디렉터리의 파일은 보존

git reset HEAD : git add한 [파일 전체] 취소, 수정된 워킹 디렉터리의 파일은 보존

2) commit 취소하기

  • git reset HEAD^ : commit 취소 (위와 동일)
  • git reset HEAD~2 : 마지막 commit 2개 취소.
  • git reset [commit_id] : git add를 한 상태에서, 변경된 staging area를 무효화 (수정된 내용은 유지)
    • git reset --soft [commit_id] : [commit_id]으로 되돌림. staged 상태, 워킹 디렉터리의 파일 보존.
    • git reset --soft HEAD^ : 직전 commit 취소. staged 상태, 워킹 디렉터리의 파일 보존.
    • git reset --mixed [commit_id] : [commit_id]으로 되돌림. unstaged 상태, 워킹 디렉터리의 파일 보존
    • git reset --mixed HEAD^ : 직전 commit 취소. unstaged 상태, 워킹 디렉터리의 파일 보존(기본 옵션)
    • git reset --hard [commit_id] : [commit_id]으로 되돌림. unstaged 상태, 워킹 디렉터리의 파일 삭제. 즉 모두 취소.
    • git reset --hard HEAD^ : 직전 commit 취소. unstaged 상태, 워킹 디렉터리의 파일 삭제. 즉 모두 취소.

3) git push 취소하기

주의 사항

  1. local의 내용을 remote에 강제로 덮어쓰기를 하는 것이기 때문에 주의.
  2. 되돌아간 commit 이후의 모든 commit 정보가 사라지기 때문에 주의.
  3. 협업 프로젝트에서는 동기화 문제가 발생할 수 있으므로 주의
  • 방법 1
    • 과정
      1. 워킹 디렉터리에서 commit을 되돌린다 →
      2. 되돌려진 상태에서 다시 commit을 한다 →
      3. 원격 저장소에 강제로 push 한다.
    • 명령어 순서
      1. git reset HEAD^ / git reset [버전명]
      2. git commit -m "변경한 메시지"
      3. git push origin +[branch] : 해당 branch를 원격 저장소에 강제로 push ('+' 붙여야 함)
      4. git push origin [branch ] -f : 해당 branch를 원격 저장소에 강제로 push
  • 방법 2
    • git revert [commit_id] : 해당 커밋만을 되돌림
    • git revert [commit_id1..commit_id2] : 해당 범주의 커밋을 모두 되돌림

4) git merge 취소하기

  • git reset -merge ORIG_HEAD
    • master와 child 두 브랜치가 있을 때, master 브랜치에서 child 브랜치를 병합하려고 했는데 병합을 하면 안 되는 작업이었던 것이 었다면, 이 경우에 병합을 한 후, 바로 병합을 취소
    • 병합은 위험한 작업이기 때문에 Git은 병합을 하기 전에, 최신 커밋에 포인터를 지정( ORIG_HEAD )합니다.
    • 따라서 방금 병합한 것을 되돌리려면 -merge 옵션과 ORIG_HEAD 포인터를 지정하여 reset 명령어를 실행하면 됩니다.
  • git revert --mainline 1 {취소할 병합 커밋 ID}
    • revert의 --mainline 옵션을 사용해서 병합을 취소할 수 있습니다.
    • mainline이란 병합을 취소한 후에, 어느 라인을 기준으로 되돌아갈 것인지 기준을 정하는 것입니다.
    • 명령어를 실행하면 편집기 창이 나오면서 커밋 메시지를 작성하라고 합니다.

5) git reset VS git revert

  • 단순하게 되돌릴 시점 이후의 commit을 전부 날리고 remote repository에 강제로 push 하여 되돌리려면 reset을 사용하면 된다 - commit history를 단순하게 만들어 준다

이미 원격 리파지토리에 push를 한 상태라면 reset을 사용하면 reset 하기 이전으로 되돌리기 전까지는 push 할 수 없게 됩니다. (물론 force라는 무시무시한 옵션이 있기는 합니다. )

따라서, 여러 문서들에서는 이미 push 한 코드에 대해서는 revert를 사용할 것을 추천하고 있네요...ㅎㅎ (정확하지 않습니다.)

  • 하지만 이력 중간에 로그 출력하도록 한 커밋이 있고 그 커밋만을 취소하려고 한다면 revert를 사용하여 해당 커밋의 내용만 되돌릴 수 있다.

3. 협업용 github 사용

1. upstream에 대한 이해

  • git remote add upstream [remote repository URL 주소] : upstream [주소] remote
  • git branch -r : -r 붙이면 원격 저장소의 branch list 확인
  • git branch -v
  • git fetch upstream : upstream 저장소에 있는 변경사항들을 로컬로 가져오면서 새로운 branch 생성
  • git checkout [master] : [내 브랜치]로 현재 가리키는 branch 업데이트
  • git merge [upstream/develop] : [upstream/develop]을 내 현재 branch로 merge(동기화)
  • git push [origin] [branch] : 내 원격 repo로 push 해주면 끝

2. PR (Pull Request)

  1. upstream repository를 내 repository에 동기화하는 경우
    • 이렇게 upstream repository와 동기화 한 내 레포를 upstream 레포로 PR을 보냄
    • upstream에서 conflict가 없을 시 PR 승인
    • 다른 협업자들은 본인의 변경사항으로 PR 하기 전에 다시 1. 의 과정을 통해 본인의 레포를 upstream의 레포와 동기화한 후 PR
  2. upstream repository에 내 변경사항만 추가하고 싶은 경우
    • upstream과 동기화를 하지 않고, 협업자와 다른 파일만을 건든다면 fetch, merge 없이 PR 가능

더 알고 싶은 분은...

참고 및 출처:
[전체적인 git 명령어 참고](https://victorydntmd.tistory.com/category/Git/%EA%B0%9C%EB%85%90%EA%B3%BC%20%ED%99%9C%EC%9A%A9?page=2)
[reset, revert 사용하는 시점 참고](https://medium.com/nonamedeveloper/%EC%B4%88%EB%B3%B4%EC%9A%A9-git-%EB%90%98%EB%8F%8C%EB%A6%AC%EA%B8%B0-reset-revert-d572b4cb0bd5)

+ Recent posts