Search

OS X의 커널과 파일시스템

요약
OS X는 재미있는 커널과 파일 시스템 구조를 가졌다
게시일
2014/02/25
태그
Mac
1 more property
OS X는 재미있는 커널과 파일 시스템 구조를 가졌다.
OS X의 심장인 Mach는 마이크로 커널이다. 이 커널은 카네기 멜론 대학에서 어느 대학원생이 만들었는데, 스티브 잡스가 이 커널에 매료되어 그를 NextStep에 데리고 왔다.
여기에 kext 확장자를 갖는 커널 모듈을 붙여 확장한다. 여기까지는 리눅스 커널과 비슷한 방식.
마이크로 커널만으로는 사용자 인터페이스를 열어줄 수 없다. 그래서 POSIX 표준 API를 커널 위에 얹었다(OS X는 Unix 머신이다).
NextStep에서 개발한 그래픽 렌더링 라이브러리는 PostScript를 사용해 스스로 PDF를 렌더링한다. 이것이 유려한 폰트를 보여주는 이유.
애플리케이션 API를 부를 때 흔히 Cocoa라 부른다. 이전에 사용하던 API는 Carbon인데, 지금은 사용하지 않는다. OS 9에서 OS X로 이행할 때 사용하던 과도기 API다.
대부분의 Cocoa 함수는 NS로 시작하는데, 이것은 NextStep의 약자.
한 때 Rosetta라는 라이브러리를 제공했다. 이것은 PowerPC Mac 애플리케이션을 Intel Mac에서 실행하도록 도와주는 일종의 에뮬레이터. 지금은 사용하지 않는다.
파일 시스템으로 HFS+를 사용하는데, 일반 Mac 머신과 Mac Server의 파일 시스템 옵션은 약간 차이가 있다(서버용 파일 시스템은 대소문자를 구분한다).
HFS+ 파일 시스템에서 대소문자를 구분하도록 디스크를 포맷할 때 선택할 수 있지만 비추. 게임이 제대로 설치되지 않는다. 대부분의 일반 사용자용 소프트웨어는 대소문자를 구분하지 않는 파일 시스템을 가정한 듯.
Windows 와 비교할 때, OS X는 32비트에서 64비트로 손쉽게 마이그레이션했다. 그 비결은 Universal Binaries라는 독특한 파일 구조 때문인데, Apple은 Xcode를 이용해 컴파일할 때 32비트 코드와 64비트 코드를 모두 하나의 애플리케이션에 집어 넣을 수 있게 했다. 그래서 사용자가 32비트 OS X를 쓰든, 64비트 OS를 쓰든, 상관없이 실행되는 애플리케이션을 제공했다.
OS X의 64비트 마이그레이션은 점진적으로 이뤄졌는데, 10.6 Snow Leopard에서 10.7 Lion으로 옮겨갈 때는 대부분의 OS 바이너리가 64비트로 바뀌었다. 이 시점에 PowerPC용 바이너리를 Intel 플랫폼에서 실행할 수 있게 해주던 Rosetta는 역사의 뒤안길로…
64비트로 실행되는 OS라도, 특정한 하드웨어에서는 커널을 32비트로, 애플리케이션은 64비트로 구동했다. 2007년 하반기에 출하된 MacBook들이 전형적인 예.
루트 디렉터리에서 소문자로 시작하는 디렉터리들, 그리고 파일들을 볼 수 있다. 이 것들은 OS X가 시스템 레벨에서 사용하거나, Unix 시스템으로 동작할 때 팔요한 것들이므로 지워서는 안된다. 대문자로 사작하는 디렉터리들은 GUI 수준에서 시스템과 사용자가 그래픽 기반 OS X를 실행할 때 필요하다. 일부 파일은 소프트 링크가 걸려 있어서 Unix 환경에서 호출된다.
파인더(Finder)에서 파일 확장자를 볼 수 있게 설정해두면, 애플리케이션들이 모두 app 확장자를 갖는다는 걸 알게 된다. App 확장자를 갖는 애플리케이션 파일은 실제로는 데렉터리다. 팝업 메뉴에서 Show Packages(영문 기준)를 클릭하면 새 파인더 창에서 애플리케이션을 구성하는 디렉터리를 볼 수 있다.
애플리케이션이 실제로는 폴더 구조이기 때문에 32비트 실행코드와 64비트 실행코드를 함께 넣기 쉬웠을거다… Xslimmer같은 애플리케이션은 애플리케이션 폴더에서 32비트 코드나 불필요한 언어 파일을 제거해주는데, 이렇게 하면 애플리케이션 크기를 “매우 많이” 줄일 수 있다. 게다가 HFS+ 파일시스템은 성능저하 없이 자체적인 파일 압축 기능을 제공한다(라지만, NTFS에서도 가능하다. 물론, 사용자가 지정해줘야 한다).
개인적으로는 이러한 애플리케이션 폴더의 특성이 샌드박싱을 더 쉽게 만들어주는 것 같다. 거꾸로, 시스템 레벨에서 어떤 취약성을 갖는 라이브러리를 업데이트해도 특정한 애플리케이션은 내부에 취약한 라이브러리를 갖고 있을 수 있다.
옛날엔 iWorks로 작업한 파일들도 실제로는 폴더였다. 이전 버전에서는 XML 기반 파일을 zip으로 묶어서 파일 확장자만 Pages, Keynote, Numbers에서 사용하는 것으로 바꾸었었다(이건 MS Office도 마찬가지). 그러나 iWorks 최신버전은 바이너리 포맷 문서 파일을 사용한다. iOS에서도 동일한 기능을 제공하려다 보니 일종의 메모리 덤프 구조로 간 것같다. CPU 컴퓨팅 파워를 줄여서 전력 효율을 줄일 수 있었을거다.