4-1. 추상화
필요 이유: 구체적인 하드웨어 특성을 사용자가 몰라도 되게 하려고. OS가 추상화를 일상적으로 해야함. 추상화 레벨이 있음.
OS는 자원을 관리하기 위해 하드웨어를 logical한 자원으로 추상화함. 그리고 이런 자원들을 관리하기 위한 인터페이스를 가져야함. 스마트폰이면 아이폰이든 갤럭시든 상관없이 동일한 인터페이스를 가져야한다. ex) 통화버튼을 누르면 번호가 뜨고 번호를 입력하면 전화가 걸린다
Kernel area에서는 추상화된 cpu만 알고 있ㅁ음. 네가 누군지 자세히 모르지만 넌 CPU야!
-리소스를 사용하게 만들어주는 추상화
- 프로그램(명령어의 집합이 추상화)
- 프로세스(cpu, 메모리 같은 자원을 사용하기 위한 추상화)
- Files (storage 추상화 / 파일이라는 개념으로 사용. cpu와 메모리를 쓸때 프로세스라는 형태로 단일하게 쓸 수 있음. 인텔 cpu든 암 cpu든 상관 x)
- Socket (파일의 일종. 읽고 쓰며 네트워크를 액세스하여 remote 서버와 통신. 인터넷만 연결되어있으면 됨. -> 추상화가 필요한 이유)
-추상화가 제공하는 것
- 어플리케이션을 쓰기 편하게 해줌
- OS가 관리를 편하게 하게 해줌. 하드웨어 종류가 너무 많으니까 공통 특징만 뽑아 추상화하여 제공.
HAL
- 하드웨어의 구체적인 특성을 숨기고 일관된 추상화된 하드웨어로 윗 계층에 제공하는 역할 수행
- 예전 OS에서는 실질적인 SW계층으로 다양한 역할을 했지만 현재는 단순히 추상화된 HW를 제공(디바이스 드라이버의 역할)
- OS가 관리할 HW는 매우 많고 다양하기 떄문에 관리가 어려워 추상화를 사용함.
- 리눅스의 경우 입출력 장치를 추상화하여 지원
HDD vs SSD 추상화
cpu, 메모리는 구체적인 장치들간의 차이가 없음. 따라서 추상화가 필요없음. 하지만 스토리지는 차이가 많아 추상화가 필수임.
| HHD | SSD | |
| 데이터 저장 방식 | 자기 | NAND Flash memory chip (비휘발성) |
| 데이터를 읽기위해 알아야하는 것 | 플래터, 플래터 안에 트랙, 트랙 안의 sector | 채널, 채널 안의 bank, 안에 block, 안에 pages |
1단계 추상화 (block storage)
- HDD와 SSD의 차이... os: 골치아파! 그냥 내가 말하는 대로 동작이나 해! -> LBA방식으로 블락 스토리지됨
- LBA 방식을 지원하기만 하면 블락 스토리지됨. N번째 주소에 512바이트씩 저장. 즉, logkcal block adressing이 LBA기법을 통해 블락 스토리지로 추상화됨.
- OS가 요구하는 것: 스토리지에는 데이터를 저장할수있는 공간이 있고 나는 거기에 0번부터 번호를 붙여서 부르겠다. 칸의 크기는 5012바이트(읽기쓰기 가능)->하드디스크 입장에서는 OS가 1번을 요청하면 실린더 0번, 헤드0번, 섹터 1번에 데이터 저장....
2단계 추상화(file system)
- 사용자들은 보통 블락 디바이스를 이용하지 않고 파일이라는 abstraction을 사용함.
- 실제 디바이스 위에 블락 디바이스, 그 위에 파일시스템. 아래에 블락 디바가 있기만 하면 파일 시스템을 얹을 수 있음
- 앱이 블락 스토리지를 신경쓰지 않아도 됨. LBA는 몰라도 데이터를 파일에 저장하고 접근할 수 있음.
- os 0.c라는 파일을 다룬다고 했을떄 이것은 또 하나의 공간. LBA의 0, 1 ,2번 블락을 써서 이 데이터를 저장할 수 있음.
CPU의 추상화
- ISA가 CPU를 구분하는 기분. 동일한 ISA를 가지면 동일한 CPU로 간주함.
- computation(주어진 operation을 흐름에 따라 처리), control(0으로 나누려고 하는 등의 interrupt가 발생하면 정해진 동작에 따라 제어) 이 두가지 조건만 맞춰주면 어떤 CPU인지 신경 안씀.
- ex) 메모리에 데이터저장하고 이 메모리에 접근해서 데이터 가져와야하는데 데이터, 메모리가 없으면 CPU가 놀라서 OS에게 알려줌. 네트워크에서 패킷이 왔다고 알려줌. 0으로 나누려고 했다고 알려줌.
- os입장에서 CPU는 OS가 하라는 일 하다가 이벤트 발생하면 OS부르고 OS가 다시 시작할 주소를 알려줌.
프로그램이 만들어지는 과정
Source Code를 짠다 -> Compile하기 -> ISA를 고려하여 머신 랭귀지로 변환해서 object file 만듦. CPU에서 실행가능한 파일 -> Linker(결합) -> 특정 OS에서 실행 가능한 Executable file 만듦. 프로그램 이미지라고 부르기도 함.
윈도우에서 쓰는걸 리눅스로 가져와서 실행하면 실행이 안됨. 둘 다 인텔인데 왜 안될까? 윈도우의 loader != 리눅스의 loader. 해석하는 방식이 다른 것. 여기서 여기까지는 코드고 여기는 엔트리 포인트고.. 이걸 누군가가 정의하고 이에 따라 로딩해야함. 이 방식이 윈도우와 리눅스가 다른 것. 리눅스가 윈도우에서 쓰던걸 해석 못함. 리눅스의 executable 파일이 아니니까.
Process Concept
정의: 실행중인 프로그램. 리소스를 공유하기 위한 추상화. 바구니 같은 느낌. 프로그램 이미지는 파일의 집합이고 프로세스는 실행중인 프로그램임. 구분하기!
- 내 바구니를 남이 접근할 수 없음. 반대도 성립.
- Context와 Resources로 구성됨.
- Context: 수행 흐름. 여러개의 수행 흐름이 존재할 수 있음.
-쓰레드. 같은 쓰레드끼리는 프로텍션 도메인이 없어서 접근할 수 있음 하지만 데이터 공유가 쉬움. 하나의 프로세스 안에는 최소한 하나의 쓰레드 존재. 그 안에 여러개의 쓰레드 존재가능. 각 쓰레드는 context를 관리하기 위한 추상화이다. - Resources: 프로세스에 할당된 자원(메모리가 가장 주됨)
-메모리: virtual address space. text, data, heap, stack 영역으로 구분. 하나의 프로세스는 하나의 address space만 가짐. 무조건 하나!! 프로세스 != address space. 메모리는 프로세스 단위로 할당됨. 쓰레드 아님. 쓰레드로 프로세스를 동작시키기 위한 요소중 하나. 이전 리소스들을 할당하는 단위가 프로세스가 됨. 파일과 소켓을 열면 그건 프로세스에 할당된 자원.
-Starage: 오픈된 파일. 파일이 바로 할당되는게 아니라 오픈을 하면 프로세스가 그 파일을 씀.
-