WIPI 플랫폼에 포팅하기

Posted 2006.12.26 02:26
WIPI 플랫폼 포팅의 일반적인 문제점

일반적인 응용 프로그램을 WIPI 플랫폼에 이식하는 데는 여러 가지 어려움이 따른다. 포팅의 어려움은 기존 플랫폼과 WIPI 플랫폼의 차이에서 기인하는데, 그 이유로 (1) 멀티 쓰레드 지원의 부재, (2) 컴팩션 하는 메모리 사용을 들 수 있다.

(1) 멀티쓰레드 지원이 없다.

WIPI-Java는 자바 언어(java.lang.Thread 클래스)를 통해 멀티쓰레드를 제공하는 데 비해서 WIPI-C는 멀티쓰레드를 지원하지 않는다. 따라서 멀티쓰레드로 작성된 프로그램을 WIPI로 옮기기 위해서는 많은 수정이 필요하다.

(2) 컴팩션(compaction)하는 메모리를 사용한다.

WIPI에서 동적으로 할당된 메모리의 컴팩션을 지원한다. 따라서 MC_knlAlloc(), MC_knlCalloc(), MC_knlFree()는 포인터가 아닌 메모리 식별자(ID)를 사용한다. MC_GETDPTR(mID)를 사용하면 메모리 식별자를 통해 메모리 포인터를 얻어올 수 있다. 메모리가 컴팩션이 일어나면 식별자를 통해 얻어온 포인터가 더 이상 유효하지 않을 수 있으므로, MC_GETDPTR()를 호출해 포인터를 다시 얻어와야 한다.

컴팩션이 일어나는 경우는 (1) 미사용 메모리가 없는 경우와 (2) MC_knlGetFreeMemory() API를 호출했을 때, (3) 내부적으로 메모리를 할당하는 일부 API를 호출했을 때뿐이므로, 매번 포인터를 얻어와야 하는 번거로움은 피할 수 있다. 하지만 (1), (2), (3)의 경우로 컴팩션이 일어날 수 있는 API를 호출한 후에는 반드시 MC_GETDPTR()를 통해 포인터를 다시 얻어와야 한다.

일반적인 응용 프로그램은 malloc()/free()와 유사한 동적 할당을 사용하고 메모리 식별자가 아닌 포인터를 직접 얻어온 후에, 해제할 때까지 영구적으로 사용한다. 따라서 이런 프로그램을 WIPI 플랫폼으로 옮길 때는 수정이 필요하다. 수정은 보통 다음 2가지 방법으로 이루어질 수 있다.

첫 번째 방법은 포팅할 응용 프로그램의 메모리 할당 방식을 WIPI의 방식으로 변경하는 것이다. 이는 응용 프로그램의 코드를 상당히 많이 고쳐야 하는 문제가 있다. 두 번째 방법은 WIPI의 MC_knlAlloc() 혹은 MC_knlCalloc()을 이용해 큰 메모리 블록을 얻어온 후에(혹은 정적 메모리 할당 이용) 응용 프로그램 내부에서 malloc()/free()와 유사한 동적 메모리 관리 알고리즘을 구현해서 사용하는 것이다. 하지만 WIPI의 일부 API는 여전히 메모리 식별자를 인자로 요구하므로, 문제를 100% 해결할 수는 없다.

WIPI란?

WIPI(Wireless Internet Platform for Interoperability)는 이동통신 단말기용 응용 프로그램 실행환경을 표준화한 규격이다. 쉽게 말하면, 국내에서 SKT, KTF, LGT 핸드폰에 공통적으로 동작하는 응용 프로그램을 작성하기 위해서는 위피 표준 규격을 따르면 된다는 뜻이다. 규격 제정 이전에는 SK의 GVM, SK-VM과 KTF의 MAP, BREW, LGT의 CLDC/MIDP 등의 플랫폼이 각기 따로 존재하였다. 때문에 응용 개발자 입장에서는 하나의 응용 프로그램을 배포하려면 무수한 포팅 과정을 거쳐야했다. WIPI는 이런 상황을 완화하고 포팅의 어려움을 덜어주고자 제안된 통합된 플랫폼이다. 현재 위피는 WIPI-자바와 WIPI-C라는 두 가지 언어 환경을 제공하고 있고 일련의 API를 표준화하여 제공하고 있다.


(1)에서 언급한 쓰레드 지원 문제는 WIPI-C의 구조상 쉽게 해결하기 힘들다. pthread와 유사한 쓰레드 라이브러리를 제공한다고 해도, 멀티쓰레드 프로그래밍은 WIPI의 메모리 모델과 충동하기 때문이다. 앞서 언급한 것처럼 WIPI는 컴팩션 메모리를 사용하고, 메모리 식별자로부터 포인터를 얻어와서 메모리에 접근한다. 기존의 단일 쓰레드 WIPI 프로그램의 경우 컴팩션이 일어나는 지점이 명확히 정의되어 있으므로, 메모리 포인터를 다시 얻어와야 하는 지점도 명확했다. 하지만 멀티쓰레드가 되면 프로그램 수행 도중 다른 쓰레드에 의해 언제든지 컴팩션이 일어날 수 있다. 따라서 메모리 포인터를 얻어올 때 다른 쓰레드가 컴팩션을 하지 못하도록 락(lock)을 잡는 일이 추가로 필요하다. 이렇게 되면 WIPI 플랫폼을 전반적으로 수정해야 하므로 적절한 방법이라 할 수 없다.

이렇게 되면 왠만한 프로그램을 WIPI로 가져오는 일은 절대 쉽지 않다는 사실을 알 수 있다.  WIPI에서 C언어 지원은 레거시 코드(legacy code)를 잘 가져와서 쓰자는 데 있다. 하지만 WIPI-C 플랫폼이 임베디드라는 특수한 환경을 고려하면서 둔 몇 가지 제약 사항이 이식성을 상당히 희생시켰다. 덕분에 모바일 환경에서 C 언어를 지원하려고 했던 원래의 취지와는 잘 맞지 않게 된 것은 아닐까?

신고
« PREV : 1 : ··· : 171 : 172 : 173 : 174 : 175 : 176 : 177 : 178 : 179 : ··· : 259 : NEXT »

티스토리 툴바