Linux에서 사용자 프로그램은 항상 운영 체제 커널에 대한 시스템 호출을 사용하여 장치 드라이버에 간접적으로 액세스합니까?
드라이버가 로드 가능 및 언로드 가능 모듈로 구현되면 사용자 프로그램이 커널에 대한 시스템 호출 없이 드라이버에 직접 액세스할 수 있습니까?
답변1
사용자는 시스템 호출을 둘러싸는 라이브러리 함수를 호출합니다(일반 프로그래머에게는 원시 시스템 호출이 매우 드뭅니다). 모듈 코드는 어쨌든 커널 모드에서 실행되므로 어떤 시점에서는 사용자 공간에서 커널 공간으로 컨텍스트 전환이 있어야 합니다. 이상적으로 대부분의 모듈은 표준화된 인터페이스(장치 노드, netlink 소켓 또는 inet 소켓)를 사용하므로 사용자 측 상호 작용은 주로 시스템 read()호출을 통해 이루어집니다 write()( ioctl또한 표준 시스템 호출이 아닌 "추가" 설정을 다루기 때문에 일반적입니다) . 버퍼는 호출 수를 줄이지만 결국에는 시스템 호출이 포함됩니다.
답변2
커널 모듈은 커널 공간에 존재하므로 정의에 따라 사용자 공간에서 액세스할 수 있는 시스템 호출이 필요합니다.예그들에 대해.
그러나 궁극적으로 실행하려면 시스템 호출을 해야 하지만 일부 커널 드라이버 위에 구축된 사용자 공간 드라이버를 만드는 것이 가능합니다. 이는 I2C 장치에서 가능합니다. 사용자 공간 드라이버는 커널의 SMBus API(모든 시스템 호출)를 사용합니다 . 이 경우 일부 응용 프로그램은 시스템을 통하지 않고 기술적으로 드라이버의 일부 기능을 사용할 수 있지만 드라이버가 실제로 하드웨어와 상호 작용해야 한다면 이는 다시 시스템 호출입니다.
시스템 메모리(참고자료 참조)인 mmap()on 에서 (시스템 호출)을 사용할 수도 있으며 여기에는 전체 커널 공간이 포함되므로 하드웨어에 대한 액세스가 노출됩니다. 그리고 이 지도를 조작해 보세요/dev/memman mem확실히추가 시스템 호출이 필요합니다. 나는 이것이 비정상적인 것이라고 생각합니다. 부분적으로는 바람직하지 않은 방식으로 커널 자체를 회피하고 부분적으로는 한 아키텍처에서 다른 아키텍처로 이식하는 데 관련된 중복성 때문입니다 . 프로덕션 시스템에 드라이버를 배포하는 것보다 해킹 및 실험에 더 적합합니다.
read()커널 드라이버는 사용 및 조작이 가능한 사용자 공간에 장치 노드 기반 인터페이스를 노출할 수 있습니다. write()이것이 바로 시스템 호출입니다.
1. 일반 커널 드라이버를 작성하거나 커널 사용자 영역 API를 사용하는 경우 이식성 문제는 커널 자체에서 해결되며 한 가지 코드 버전을 사용할 수 있습니다. 메모리 매핑 접근 방식을 사용하는 경우 각 아키텍처마다 서로 다른 버전의 코드가 있어야 합니다(커널에 이미 있으므로 "중복"됨).