저는 장치 드라이버가 어떻게 작동하는지 이해하려고 노력하고 있으며, 지금까지 제가 알고 있는 바로는 장치 드라이버는 운영 체제와 장치 사이의 "중간자"일 뿐입니다. 장치 드라이버에 대한 이해를 보여주기 위해 다음 다이어그램을 만들었습니다.
또한 응용 프로그램은 장치 드라이버와 직접 상호 작용할 수 없으며 운영 체제에서만 이를 수행할 수 있습니다. 예를 들어 응용 프로그램이 무언가를 인쇄하려는 경우 운영 체제에 "알려주고" 운영 체제는 장치 드라이버에 알립니다.
내 이해가 맞나요? Windows 및 macOS의 장치 드라이버 개념은 Linux와 동일합니까?
답변1
아주 간단하게:
장치 드라이버에서 가장 중요한 점은 커널 공간에서 실행되고 커널과 동일한 권한을 가지므로 하드웨어에 직접 액세스할 수 있다는 것입니다. 응용프로그램은 (보통) 이것을 허용하지 않습니다.
따라서 장치 드라이버는 일부 하드웨어("장치")에 대한 액세스를 구성하는 커널의 일부로 생각할 수 있습니다.
/proc/애플리케이션은 더 높은 추상화(예: 파일 시스템)부터 중간 추상화(블록 장치), 매우 낮은 수준의 추상화( 또는 의 일부 파일 /sys, ioctls장치의 일부 파일 /dev) 에 이르기까지 다양한 수준에서 커널과 상호 작용할 수 있습니다. 따라서 낮은 수준의 상호 작용은 때때로 커널이 호출을 장치 드라이버로 리디렉션하는 매우 얇은 계층을 사용하여 장치 드라이버와 매우 직접적으로 통신합니다. 따라서 "응용 프로그램은 장치 드라이버와 직접 상호 작용할 수 없으며 운영 체제에서만 그렇게 할 수 있습니다"는 사실이기도 하고 거짓이기도 합니다.
또한 그림에서 설명한 것처럼 커널에는 많은 추상화 계층이 있습니다("운영 체제에서 보낸 메시지는 동일하며 장치 드라이버는 하드웨어와 통신하기 위해 다른 메시지를 사용합니다). 예를 들어 블록 계층은 USB 레이어는 하나의 메시지를 수신하지만 다른 USB 호스트 컨트롤러를 사용할 수도 있습니다.
따라서 상황은 훨씬 더 어렵습니다. 커널에는 계층과 하위 시스템이 있고 실제로 하드웨어와 통신하는 장치 드라이버는 해당 계층 구조의 맨 아래에 있습니다. 상황을 더욱 혼란스럽게 만드는 것은 장치 드라이버 및 기타 계층이 모듈(Linux용) 형태로 제공된다는 것입니다. 를 입력하면 lsmod어떤 모듈이 활성화되어 있고 어떤 모듈이 어떤 다른 모듈을 사용하는지 확인할 수 있습니다.
또한 인쇄는 정말 나쁜 예입니다. 대부분의 프린터별 처리는 장치 드라이버가 아닌 사용자 공간에서 발생합니다.
Windows, Linux 및 MacOS는 모두 이러한 원칙을 따르지만 세부 사항은 크게 다릅니다.
이것이 도움이 됩니까?
편집하다:
오늘날 Linux에서의 인쇄는 일반적으로 다음을 통해 수행됩니다.컵. Cups에는 다양한 프린터용 문서를 렌더링할 수 있는 다양한 프로그램이 있습니다. 이러한 모든 프로그램은 파일(문서는 pdf/postscript/...)을 가져와 프린터가 이해할 수 있는 형식의 다른 파일로 변환합니다. 이 모든 작업은 커널 외부에서 발생합니다. 이 중 어느 것도 실제 하드웨어에 액세스할 필요가 없기 때문입니다. 단지 파일을 읽고 쓰는 것뿐입니다. 변환된 데이터를 프린터로 보낼 때 마지막 부분만 커널을 사용합니다. 그런 다음 동일한 유형의 프린터라도 네트워크, USB, 직렬 연결 등 다양한 경로를 사용할 수 있습니다. 마지막 부분은 일반적으로 프린터와 관련이 없습니다.
따라서 Linux는 실제로 대부분의 프린터에 대한 프린터별 장치 드라이버를 제공하지 않습니다. (여러 프린터의 경우 하나가 필요할 수 있습니다).
답변2
장치 드라이버는 운영 체제와 장치 사이의 "중개자"일 뿐입니다.
예, 그 정도입니다.
장치 드라이버는 표준화된 프로그래밍 호출을 하드웨어 구성 요소에 대한 장치별 작업으로 변환하는 "블랙 박스"입니다.
이런 방식으로 프로그램은 특정 하드웨어의 내부 작동을 알 필요가 없습니다. 특정 장치 드라이버는 투명한 방식으로 매핑되어 프로그램이 하드웨어와 "대화"할 수 있습니다.
이는 커널과 별도로 구축되고 필요할 때 활성화됩니다(모듈로 커널에 로드됨).