장치 드라이버가 아닌 커널 모듈을 작성해야합니다. 이 모듈은 일부 사용자 공간 프로세스와 통신합니다. ioctl()을 사용하고 싶지 않기 때문에/proc 디렉토리에 파일을 만들거나/dev 디렉토리에 장치 파일을 생성 할 수 있습니다./proc 및/dev를 사용하는 경우
질문 : 어떻게하면/proc와/dev 사이에서 결정할 수 있습니까? 이것은 단지 판결 요청일까요, 아니면이 두 가지를 사용하는 것에 대한 어떠한 쓴 계약도 없습니다.
/proc /에 새 인터페이스를 추가하는 데 많은 어려움이 있습니다. 커널 개발자는 여러 인터페이스에 대한 덤프가되어 불만을 가지고 있습니다. 실제로/proc/pid /를 통해 프로세스에 대한 내용을 수정하지 않으면 커널 커뮤니티가이를 받아들이도록 설득하는 데 어려움을 겪을 것입니다.
실제로 장치 드라이버가 아닌 모듈의 경우에도/dev /에있는 장치 파일을 사용할 수 있습니다. (예 :/dev/kvm,/dev/pts,/dev/ecryptfs,/dev/fuse,/dev/kmsg,/dev/ptmx 등) 그러나 장치 파일은 너무 자주 ioctl) 나는 할 수 있으면 그것을 피할 수 있다고 생각합니다.
커널 서클의 현재 트렌드는 sysfs 또는 사용자 정의 파일 시스템입니다. sysfs 접근 방식은 에코와 고양이로 조작되도록 의도 된 파일 당 단일 값 의미에 기반합니다. 그것은 당신을 위해 작동한다면 그것은 사용자를 위해 훌륭합니다. 사용자 정의 파일 시스템을 사용하면 매우 특정한 바이너리 가능 인터페이스를 작성할 수 있으며 fs/libfs.c는 사용자 자신의 필요에 맞게 파일 시스템을 작성하는 데 도움이됩니다. (configfs를 사용하는 사람은 알지 못하지만 항상 깔끔하게 보였을 것입니다. 아마도 모듈에 맞을 것 같습니까?)
sarnold는/dev /에 표시된 객체를 가리켜 " 진짜 "장치. 드라이버가 POSIX 유형 인터페이스 (공개/읽기/쓰기)를 제공하는 경우 사용하지 않을 이유가 없습니다. 사용자와 커널 공간간에 어떤 종류의 의사 소통을 계획합니까? – stsquad
우리 소프트웨어의 일부가 시스템 성능에 영향을 미치는 너무 많은 시스템 호출을 만듭니다. 이러한 호출의 부담을 피하기 위해 커널 공간으로 옮길 계획입니다. 본질적으로 커널과 사용자 공간 간의 통신에는 대규모 데이터 전송이 필요합니다. 어느 누구라도이 문제에 대한 다른 기법을 제안 할 수 있다면 매우 감사 할 것입니다. – binW
시스템 호출이 커널 공간에서 훨씬 빠르다는 사실을 알지 못합니다. 최소한 커널 공간에서 많은 양의 데이터를 복사하는 데 드는 추가 비용보다 중요합니다. 즉,'mmap'을 구현하는 문자 장치 파일을 조사하십시오. – caf