Kernel Extensions

OSXDEV

다윈/Mac OS X은 재컴파일 없이 코드를 동적으로 커널에 올릴 수 있는 커널을 확장할 수 있는 매커니즘을 제공한다. 이 코드는 흔히 플러그-인 또는 다윈 커널에서는 커널익스텐선 커널익스텐션(KEXT)라고 한다.

[편집] KEXTs를 남발하면 안되는 이유

KEXT가 모듈성과 동적로딩을 지원하기 때문에 커널의 내부적인 인터페이스에 대한 접근이 필요한 self-contained서비스를 위해서는 확실한 선택이다. 비록 다른 방법들이 있지만 많은 커널 환경의 컴포넌트들이 이 익스텐션 매카니즘을 지원한다.

예를 들어, 몇몇 새로운 네트워킹 요소들은 네트웍 커널 익스텐션(NKEs)를 사용한다. 새로운 파일시스템을 동적으로 추가하는 기능은 VFS KEXTs에 기반하고 있다. 디바이스 드러이버들과 I/O 킷에 있는 device family들은 KEXTs를 이용해서 구현되어있다. KEXTs는 개발자들에게 드라이버를 작성하거나 새로운 볼륨 포맷을 지원하거나 네트워킹 프로토콜을 지원하게 하는것을 쉽게 해준다.

KEXTs가 커널 어드레스 스페이스의 슈퍼바이저 모드에서 작동되기 때문에 커널 익스텐선들은 유저레벨 모듈들에 비해서 작성하기도 힘들고 디버깅하기도 힘들며 엄격한 가이드라인에 따라 작성 되어야 한다. 게다가, 커널 리소스는 영구적(컴퓨터가 켜져있는 한)으로 메모리에 고정되어 있고 동일한 기능에서 유저 스페이스 테스크에 비해서 더 많은 부하가 걸린다. 게다가, 메모리 프로텍션이 애플리케이션으로 부터 시스템 크래쉬를 막아주는 반면 커널 내부에서는 그런 안전장치가 없다.

Mac OS X에서 잘못 짜여진 커널 익시텐션은 Mac OS 8이나 9에서의 그것 보다 더 많은 문제를 야기시킨다. KEXTs 내의 버그는 유저레벨의 코드보다 더 치명적인 결과를 만들어 낸다. 예를 들면 유저 애플리케이션에서의 메모리 엑세스 에러는 최악의 경우 애플리케이션의 크래쉬의 원인이 되지만 KEXT에서의 메모리 엑세스 에러는 시스템 패닉과 오퍼레이팅 시스템의 크레쉬와 직결된다. 결국 이런 단점으로 인한 보안문제로 어떤 고객들은 써드파티 KEXTs를 제한하거나 허용하지 않는다.

결과적으로, 유저레벨에서 구현 가능하다면 KEXTs를 이용하는것은 좋지 않다. 다윈은 유저 쓰레드가 커널 스레드 만큼 효과적이라는 것을 보장하므로 효율성은 이슈가 되지 않는다.

다윈/Mac OS X에서 코드를 만들때 애플리케이션이 커널 인터페이스나 데이타 스트림에 대한 로레벨 억세스가 필요하지 않는다면 하이레벨쪽을 이용하는것이 좋다.

만일 KEXT를 사용해야 할지 말아야 할지 결정해야한다면 일반적으로 기본적인 대답은 사용하지 말라이다.

[편집] 언제 KEXT가 필요한가

코드가 MacOS 8 또는 9의 시스템 익스텐션인 경우에도 꼭 그 코드가 Mac OS X에서 커널 익스텐션으로 작성되어야 할 필요가 없다. 개발자가 커널 익스텐션을 작성해야 하는 몇몇 이유는 다음과 같다.

코드에서 중요한 인터럽트를 처리할 필요가 있을때, 하드웨어의 어떤것이 CPU에 인터럽트를 거는 경우이다. 코드의 중요한 클라이언트가 커널 내부에 있어야 하는 경우, 예를 들면 파일시스템이 중요한 클라이언트인 블럭디바이스 같은 경우... 많은 숫자의 애플리케이션이 당신의 코드가 제공하는 리소스가 필요한 경우, 예를 들면 파일 시스템 스택을 작성하는 경우... 작성하고 있는 코드가 높은 속도와 뛰어난 동기화와 낮은 latency를 필요로 하는 멀티플 클라이언트 애플리케이션들 사이에 다중송신이 필요한 경우.

만일 프로그램이 위의 예에 해당되지 않는다면 그것을 라이브러리나 유저레벨 데몬 또는 유저레벨 플러그-인(퀵타임 컴포넌트나 Core Graphics framework같이)으로 작성한는것을 고려해야 할 것이다.

만일 디바이스 드라이버를 작성하거나 새로운 볼륨 포맷이나 네트워킹 프로토콜을 지원하기 위해서는 KEXTs가 아마 유일한 해결책일 것이다.