그림으로 배우는 리눅스 구조 6장. 장치 접근

Computer Science/OS

그림으로 배우는 리눅스 구조 6장. 장치 접근

챔🐻 2024. 2. 9. 20:33

출처: 그림으로 배우는 리눅스 구조

프로세스는 장치에 직접 접근하지 못하고 커널을 통해 접근할 수 있다.

아래와 같은 인터페이스를 사용한다.

디바이스 파일이라는 특수한 파일을 조작한다.

블록 장치에 구축한 파일 시스템을 조작한다.(7장 참조)

💡네트워크 인터페이스 카드(NIC)는 속도 등의 문제로 소켓을 사용한다.(유일하게 얘만 파일 아님)

디바이스 파일

디바이스 파일은 장치마다 존재한다.

ex) 저장 장치 : /dev/sda, /dev/sdb 같은 파일이 디바이스 파일.

디바이스 드라이버 : 프로세스가 디바이스 파일을 조작하면 대신 장치에 접근하는 SW

<디바이스 파일에 저장되는 정보>

파일 종류 : 캐릭터 장치 or 블록 장치

디바이스 메이저 번호, 마이너 번호 : 두 번호의 조합이 같다면 같은 장치임

디바이스 파일은 보통 /dev/ 디렉터리 아래에 존재한다.

ls -l /dev/ | less

crw-rw----  1 root    tty       7, 134 Oct 23 05:28 vcsa6
crw-rw----  1 root    tty       7,  64 Oct 23 05:28 vcsu
crw-rw----  1 root    tty       7,  65 Oct 23 05:28 vcsu1
crw-rw----  1 root    tty       7,  66 Oct 23 05:28 vcsu2
crw-rw----  1 root    tty       7,  67 Oct 23 05:28 vcsu3
crw-rw----  1 root    tty       7,  68 Oct 23 05:28 vcsu4
crw-rw----  1 root    tty       7,  69 Oct 23 05:28 vcsu5
crw-rw----  1 root    tty       7,  70 Oct 23 05:28 vcsu6
brw-rw----  1 root    disk    252,   0 Oct 23 05:28 vda
brw-rw----  1 root    disk    252,   1 Oct 23 05:28 vda1

첫글자

c : 캐릭터 장치

b : 블록 장치

5번째가 메이저, 6번째가 마이너

캐릭터 장치

= R, W 가능, 탐색 조작 불가능(장치 내부에서 접근 장소 변경)

ex) 단말, 키보드, 마우스

각 프로세스와 연결된 단말 : ps ax의 두 번째 필드에서 확인 가능

/dev/pts/0 : pts/0 단말에 대응하는 디바이스 파일

단말 장치에 hello 문자열을 쓰면(디바이스 파일에 write() 시스템 콜을 호출) 단말에 문자열이 출력된다. → echo hello 명령어 실행과 동일한 결과

그 이유는 echo 명령어는 표준 출력에 hello를 쓰고, 리눅스에서 표준 출력은 단말과 연결되어 있기 때문.

위 사진 보면 아무것도 하지 않은 두 번째 단말 화면에 첫번째 단말 화면에서 쓴 디바이스 파일에 쓴 문자열이 출력된 걸 알 수 있다.

블록 장치(block device)

= R, W, 탐색도 가능

ex) 하드 디스크(HDD), SDD 같은 저장장치

블록 디바이스 파일을 직접 조작하는 건 드문 일로 보통은 파일 시스템을 경유해서 데이터를 읽고 쓴다.

루프 장치

루프 장치 : 파일을 디바이스 파일처럼 다룰 수 있는 기능

비어있는 장치가 없거나 디스크에 저장된 내용이 손상될 위험이 있을 경우 루프 장치 기능 쓰면됨.

디바이스 드라이버

디바이스 드라이버 : 프로세스가 디바이스 파일에 접근할 때 동작하는 커널 기능

장치를 직접 조작하려면 각 장치에 내장된 레지스터 영역을 읽고 써야 한다.

디바이스 레지스터 ≠ CPU 레지스터

프로세스 입장에서 보는 장치 조작

메모리 맵 입출력(MMIO)

메모리 맵 입출력(memory-mapped I/O, MMIO)를 사용해서 디바이스 레지스터에 접근한다.

180~184 참고..

폴링

폴링 : 디바이스 드라이버가 능동적으로 장치에서 처리를 완료했는지 확인

→ 내가 확인

디바이스 드라이버가 장치에 처리를 요청하고 처리 완료할 때까지 확인용 레지스터를 계속 확인하기 때문에 CPU는 다른 일을 할 수 없다

→ 엄청난 자원낭비.

그래서 계속해서 확인하는 대신에 일정 간격을 두고 레지스터 값을 확인하는 폴링 방법도 있다.

인터럽트

= 시스템이 확인해서 알려줌

내가 신경쓸 필요 없기 때문에 폴링보다는 인터럽트를 장치 처리 완료 확인 방법으로 사용하는 경우가 많음.

/proc/interrupts : 시스템 시작 이후 지금까지 발생한 인터럽트 개수

Column) 일부러 폴링을 사용하는 경우

장치 처리가 빠르고 처리 빈도가 높다면 예외적으로 폴링을 사용하기도 한다.

why? 인터럽트 핸들러 호출은 어느 이상의 오버헤드가 발생하기 때문

사용자 공간 입출력(userspace I/O, UIO) : 디바이스 레지스터를 매핑한 메모리 영역을 프로세스의 가상 주소 공간에 매핑해서, 프로세스에서 장치를 조작하는 기능

디바이스 파일명은 바뀌기 마련

Uploaded by N2T