토요일, 8월 23, 2008

Protected Server Libraries - 기본 개념

protected server libraries 즉 PSL이란 것. 가끔 wince 관련 기술문서들에서 그것도 아주 아주 가끔 등장하지만 정작 그게 뭔지 제대로 설명하는 글은 거의 찾을 수 없다. 단지 'thread가 process들간을 이동(migrate)한다'는 식의 별로 도움 안되는 짧은 설명들만 있을 뿐이다. 사실 알 필요가 없어서 이기도 하겠지만 그렇다면야 아예 언급을 하지 말던가. 언급은 해 놓고 설명을 안해주는 것은 대체 무슨 심보인가? 그나마 약간이라도 설명하고 있는 책이 있었으니 'Building Powerful Platform with Windows CE'에서다. PSL을 설명하는 부분의 내용을 이해하기 쉽도록 옮겨본다. 밝혀두지만 직역이 아니고 이해 하기 쉽도록 충분히 의역해서 원본과는 상당히 다른 글이 되었있다. 심지어 원본에 없는 부가 설명도 추가했고 원본의 설명이 틀렸다고 생각되는 부분은 내 생각으로 고쳐서 썼다. 원래 이 책은 친절한 책이 못되고 그래서 읽기도 무척 괴롭다.

Slot memory 구조때문에 process들의 memory space가 서로 구분/분리 되어 있는데, 한 process에 의해서 할당된 buffer가 다른 process에 의해서 어떻게 access될 수 있을까? 이것이 가능한 것도 바로 slot구조이기 때문이다. Slot구조에서는 모든 process들이 2GB 공간에서 각자의 서로 다른 공간을 할당 받은 상태이고, kernel은 이 2GB영역을 모두 access할 수 있으므로 kernel에 의한 translation에 의해서 이것이 가능해 진다.

하나의 process가 다른 process에 있는 function을 call한다고 할때 calling process를 client process, called process를 server process라고 하기로 하자.

Client process가 server process의 function을 API로써 call한다면, 그 API를 수행하는 thread는 server process의 context에서 실행 된다. 당연한 말인데 API를 수행하는 thread는 자신이 속한 process memory space에서 동작하는 것이다. 그런데 이것은 process간에 crash를 유발할 수 있다. 왜냐하면 API를 수행하는 server process의 thread는 client process memory space의 API parameter를 가지고 server process의 context에서 작업을 수행해야 하는데, 알다시피 Windows CE slot memory 구조에서는 process간의 memory space는 구분되어 있다.

이것을 해결하기 위한 일반적인 방법은 역시 위에서 언급한 것 처럼 2GB영역을 모두 볼 수 있는 kernel의 개입에 의해서 인데, client process에 의한 API call을 kernel이 trap한 후 API parameter를 server process의 API를 수행하는 thread로 copy하여 넘기고, server process가 API수행을 완료하면, 다시 kernel이 결과를 client process에게 copy해서 넘긴다.
그러나 이 방법에는 overhead가 있는데 client process가 API call을 하려면 server process에서 API function을 수행하는 thread가 있어야 하기 때문이다. thread가 있어야 한다는 것은 이것을 위한 stack과 memory가 있어야 한다는 말인데, resource가 제약된 embedded system에서는 이런 resource 소모는 최소화 되어야 좋다. 이런 overhead를 없애기 위한 것이 바로 Protected Server Libraries다. PSL 자체가 overhead를 없애기 위한 방법이 적용된 server process다. PSL은 API set를 구현하고 이것을 kernel에 등록 시킨다. 그럼 kernel은 그 API function의 signature를 기억해 두었다가, 이전과 같이 client process에서 PSL의 API를 call하면, kernel은 client process에서 발생된 API call을 trap한 후, client process에서 API call을 발생시킨 thread를 PSL의 process space에서 run하도록 만든다. 이렇게 해서 PSL에서는 API call을 수행하기 위해서 thread를 따로 생성해야 하는 overhead를 제거할 수 있다.

Client process의 thread가 PSL로 진입할때, 이 thread는 PSL과 PSL address space로의 access권한을 자동으로 부여받게 되어 PSL 내에 존재하는 다른 thread들 처럼 동작할 수 있다. Thread가 PSL을 떠나게 되면 이 access권한도 제거된다. 모든 Slot내의 매 64Kb memory block 마다 read/write등의 여러가지 access 허가상태가 설정되어 있다. 이 slot내 memory block을 access하여 어떤 동작을 하려 하면, kernel은 그 동작을 하려는 thread가 그 memory block에 대해 올바른 access권한이 있는지 check한다. 그래서 만일 PSL이 아닌 다른 어떤 process내에서 동작중인 thread가 PSL의 memory를 modifiy하는 등의 동작을 하려하면 거부된다.

댓글 없음: