커널 개발자는 커널 기능을 노출할 때 몇 가지 옵션을 사용할 수 있습니다. 새로운 시스템 호출을 생성하거나 /sys 또는 /proc 항목을 통해 기능을 노출할 수 있습니다.
다른 것보다 하나를 선택하는 이유가 있습니까?
커널 개발자는 상당한 이점을 제공하지 않는 한 새로운 시스템 호출을 추가하는 것을 피합니까, 아니면 필요할 때 자유롭게 호출을 추가합니까?
편집하다:저는 netfilter 기능을 Linux 컨테이너(LXC)에 노출하는 프로젝트를 진행 중입니다. 기능은 제어된 방식으로 노출되어야 합니다. 예를 들어 컨테이너(예: c1)가 netfilter 후크를 배치하려는 경우 패킷이 c1의 네트워크 인터페이스용으로 의도된 경우에만 후크를 호출해야 합니다.
새로운 시스템 호출을 생성하거나 컨테이너가 모듈을 설치하도록 허용하고 게스트 설치 커널 모듈로부터 호스트 커널을 보호하기 위해 커널에 변환 계층을 제공할 수 있습니다. (이 번역 모듈의 구현이나 컨테이너가 모듈을 설치하도록 허용하는 데 따른 보안 영향은 또 다른 논의의 주제가 될 수 있습니다.)
새로운 시스템 호출을 추가하면 더 나은 격리가 보장되고, 게스트가 모듈을 설치하도록 허용하면 성능이 더 좋아집니다. 후자는 예를 들어 게스트가 자체 버전의 TCP/IP 스택을 사용하려는 경우 시스템 호출이 할 수 없는 기능을 노출할 수도 있습니다.
숙련된 Linux 커널 개발자는 무엇을 선호합니까?
답변1
새로운 시스템 호출은 거의 추가되지 않습니다. 대부분의 새로운 커널 기능은 몇 가지 일반적인 메커니즘을 통해 구현될 수 있습니다.
- 파일 설명자는 리소스 관리의 매우 일반적인 기능입니다.
- 파일 설명자에 대한 사용자 정의 작업이 전달됩니다.
ioctl
. - 상호작용은 다음을 통해서도 가능합니다.프로세스 파일 시스템그리고 그 변종시스템 파일 시스템하드웨어 및 드라이버에 대한 정보입니다.
이러한 일반 메커니즘은 기존 일반 지원의 이점을 활용합니다. 예를 들어 설명자에 연결된 리소스는 하위 프로세스와 자동으로 공유되고, execve
그렇게 하도록 표시된 경우 자동으로 닫히고, 설명자가 닫힐 때(프로세스가 종료될 때 발생) 해제됩니다. 파일로 구현된 새로운 기능에 대한 액세스 제어는 정교한 파일 액세스 제어 메커니즘(권한, SELinux 등)을 통해 제공됩니다.
이러한 일반 메커니즘은 라이브러리 지원을 기다리지 않고 즉시 사용할 수 있으므로 새로운 시스템 호출보다 사용하기 쉽습니다. /proc
새 항목은 쉘 스크립트에서 직접 사용할 수 있습니다. 새로운 기능은 ioctl
앱에서 직접 사용할 수 있습니다. 표준 라이브러리에 새로운 시스템 호출을 선언해야 합니다.
이것시스템 호출 매뉴얼 페이지각 시스템 호출이 추가된 커널 버전을 나열합니다. 대부분의 새로운 시스템 호출은 메타데이터 및 자격 증명(예: 2.6의 확장 속성 지원)을 관리하거나 이전에는 불가능했던 작업의 변형(예: execveat
) 으로 특정 유형의 파일에 대해 작동하는 새로운 방법을 제공합니다 renameat2
.
답변2
이것Linux 문서에는 새로운 시스템 호출 추가에 대한 지침이 나와 있습니다.
우리의 논의와 관련된 핵심 사항은 다음과 같습니다.
- 새로운 시스템 호출이 추가되면 커널 API의 일부가 되며 무기한 지원되어야 합니다.
- 새로운 시스템 호출을 생성하는 것은 테스트 코드, 매뉴얼 페이지를 생성하고 이를 커널 모듈로 출시하는 대신 메인라인 커널에 포함시킬 수 있는 충분한 인센티브를 포함하기 때문에 더 큰 책임이기도 합니다.
- 새로운 기능이 파일 시스템 사용과 같이 대화형인 경우(예를 들어 메모리 사용과 같은 런타임 정보는 /proc/meminfo를 읽어서 얻을 수 있음) /proc, /sys, /dev 항목을 사용하십시오. 모듈로 생성하고 필요에 따라 커널에 넣거나 꺼낼 수 있습니다. 또한 Gilles의 답변에 제공된 이점을 제공합니다.
이것들Linux 커널 문서에 있는 다른 파일의 줄은 개발 프로세스를 설명하고 사용자 공간 ABI가 노출되기 전에 수행해야 하는 작업을 강조합니다.
인터페이스가 사용자 공간으로 내보내지면 무기한 지원되어야 합니다. 이 사실은 사용자 공간 인터페이스 생성을 특히 어렵게 만듭니다. 호환되지 않는 방식으로 변경할 수 없기 때문에 처음에 올바르게 수행되어야 합니다.
따라서 사용자 공간 인터페이스에는 항상 많은 생각, 명확한 문서화 및 광범위한 검토가 필요합니다.