일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- link layer
- AINCAA
- polymorphism
- protection
- SDLC
- Waterfall
- MLFQ
- frequency-domain spectrum analysis
- 게임 개발
- 메카님
- DSP
- 배경 그림
- 게임개발
- FIFO
- SJF
- unity
- STCF
- Security
- 컴퓨터 네트워크
- stride
- information hiding
- OSI 7계층
- DP
- Trap
- 유니티
- MAC
- 유스케이스
- OWASP
- 운영체제
- Unity #Indie Game
- Today
- Total
다양한 기록
I/O Device, Device Driver 본문
디바이스
디바이스를 볼 때는 버스를 중심으로 보게 된다
과거 - 계층 구조
- 메모리 버스(시스템 버스): CPU와 메모리 용도. 빠르고 비싸고 짧음
- I/O 버스: SCSI, SATA, USB.. 느리고 싸고 긺
** I/O버스 중 빠른 애들은 별도의 버스 사용 (그래픽 카드)
모던 시스템
멀티코어, 누마 시스템 등.. -> 네트워크 형태
Special interconnect: Memory interconnect, Graphic interconnect
- Memory interconnect : 메쉬 형태. (QPI = QuickPath Interconnect, Hyperport)
- Graphic interconnect (PCIe = Peripheral Component Interconnect Express.. 주변 장치 연결 표준)
I/O 장치는 각각의 I/O 칩을 가지고 잘 정리된 약속으로 연결됨 (윈도우는 DMI)
디바이스는 interface parts와 internals로 구분
interface parts
- command register
- status register
- data register
디바이스마다 특징은 다르나 디바이스 상태 체크, 명령, 데이터 넣어주기의 기능은 있고
각각에 해당하는 레지스터가 있음
내부적으로는 복잡하나, 커맨드 스테이터스 데이터 레지스터가 핵심적
Internals
- Logic: 컨트롤러나 특별한 칩 + SW(펌웨어)
- Memory: I/O 버퍼 (받은 패킷 저장, 지연 쓰기..)
** 펌웨어: 디바이스 위에서 동작하는 소프트웨어, 명확히는 소프트웨어인데 하드웨어와 밀접함
Protocol
어떻게 디바이스들과 상호작용할 것이냐.. 4가지 단계
1. idle check
2. data
3. command
4. finish check
1. status를 보면 비지한지 아닌지 체크 가능
2. 한가하면 쓰고
3. 커맨드(프린터의 경우 - 출력)
4. 다시 idle해지면 작업이 끝난 거니까 finish
여기서 데이터와 커맨드의 순서가 바뀔 수 있음
보내줘야 하는 데이터가 길면 커맨드를 먼저 주고 타이밍에 맞게 데이터를 보내기도 함
기법
1. PIO (Programmed I/O)....Poling
2. Interrupt
3. DMA (Direct Memory Access)
PIO
모든 작업을 CPU가 함
: 프로그램 코드가 처리하게 됨
CPU 내부에서 폴링(상태 체크. 다 됐냐고 계속 물어봄)
-> 잡이 러닝 상태
1~4단계를 전부 CPU가 해결
Interrupt
다 끝나면 알려달라고 하고 슬립
디바이스가 끝나면 인터럽트를 보냄
-> 스케줄러는 레디에서 다른 거 뽑아서 그 시간에 CPU한테 다른 작업 시킴
=> 오버래핑(중첩되어 실행된다)
인터럽트나 트랩을 쓰기 위해선 핸들러와 테이블이 필요
인터럽트 발생 시엔 번호만 알려줘서 번호보고 핸들러 실행하게 됨
옛날엔 IRQ라는 걸 세팅해줬음 (내가 몇 번 인터럽트를 사용하겠다)
* 3번으로 세팅한다 -> 테이블에 3번으로 등록
또한 특징 상 컨텍스트 스위칭이 필요
무조건적으로 인터럽트가 좋은 거 아니고, 사건 발생이 빠른 경우엔 그냥 폴링이 나음
스핀락, 슬립락과 비슷
1, 4번을 인터럽트로 해결하면 인터럽트 방식
DMA(Direct Memory Access)
디스크는 느림 (ms 단위)
CPU는 나노 단위.. 대략 만배 차이
이를 해결하기 위해 CPU가 DMA 컨트롤러한테 메모리 어디부터 어디까지 읽어서 디스크에 써달라는 등의 요청 가능
-> DMA 컨트롤러가 메모리와 디바이스 간 데이터 카피를 하고 CPU는 그 시간에 다른 잡을 함
* DMA가 메모리 접근할 때는 CPU가 메모리에 접근 못하고, 내부에 캐시가 있으니 그걸로 일함
* 버스에 아비터가 있는데 버스에 대해 일종의 락을 잡는다고 볼 수 있음
** 성능 좋은 디바이스들은 디바이스 컨트롤러가 있는데 DMA컨트롤러가 디바이스 컨트롤러한테 일을 위임하기가 가능
** CPU -> DMA Controller -> Device Controller
Data 단계를 CPU에서 안하고 DMA 컨트롤러에서 함
디바이스 레지스터 접근법
1. Direct I/O
2. Memory-mapped I/O
Direct I/O
인텔에서 사용
메모리 주소(디램)와 I/O 주소를 따로 구분해줌
100번지가 메모리인지 IO인지는 사용하는 명령어에 따라 구분됨 (move / in, out)
Memory-mapped I/O
메모리 주소 공간 하나에 일부가 I/O
같은 명령어로 주소 공간에 접근
둘 다 IO는 특권 명령어로만 접근 가능
커널 모드로 들어가서 커널한테 접근해달라고 해야 함
디바이스 드라이버
커널 레벨에서 디바이스를 제어하는 소프트웨어
두 층으로 이루어짐
1. Device-specific
- 디바이스 레지스터(커맨드, 스테이터스, 데이터)
- 인터럽트
- DMA
2. OS-specific
- open, read, write 등의 인터페이스 제공 (like file)
디바이스 드라이버의 종류
- 문자 디바이스 드라이버
- 블록 디바이스 드라이버
문자 디바이스 드라이버
터미널, 키보드 등의 문자 장치
문자 디바이스는 직접 오픈하고 리드, 라이트, 클로즈 가능
블록 디바이스 드라이버
디스크는 직접 접근을 안하고 파일 시스템을 통해서 접근함
파일을 오픈, 리드, 라이트
IDE Disk Driver 예시
IDE는 옛날 거라 스테이터스랑 커맨드를 하나로 씀
읽으면 스테이터스 쓰면 커맨드
에러 레지스터는 에러의 원인을 넣는 곳
리퀘스트 시작 전 wait하는 모습도 볼 수 있음
* 문자 장치는 리드와 라이트가 별도인데 블록은 한 함수로 하는 경우가 많음
'운영체제' 카테고리의 다른 글
파일과 디렉토리 (0) | 2024.05.19 |
---|---|
Hard Disk Drive / Time io, Time rate / Disk Scheduling (0) | 2024.05.19 |
데드락 (0) | 2024.05.06 |
Semaphore (세마포) (0) | 2024.04.18 |
조건 변수, 생산자/소비자 문제 (0) | 2024.04.18 |