Search Results for '포팅'

3 POSTS

  1. 2008.02.27 libmms 포팅 1
  2. 2006.12.26 WIPI 플랫폼에 포팅하기 2
  3. 2006.12.22 마이크로소프트웨어 1월호 원고

libmms 포팅

Posted 2008. 2. 27. 00:55
리눅스 쪽에서 mms/mmsh 스트리밍 소스를 사용하기 위한 libmms라는 프로젝트가 있습니다. 현재 0.4까지 올라와있습니다.

저는 오늘 GStreamer Plug-ins Bad에 있는 libmms 플러그인을 사용하기 위해 libmms를 윈도로 포팅하는 작업을 했습니다. 윈도 GStreamer에서 mms 소스를 간단히 테스트하려고 시작했는데, libmms가 제대로 포팅이 안 되어 있어서 조금 고쳐서 해본다는 게 결국 꽤 많은 코드를 수정하게 되었군요. 역시나 버리기 아까워서 패치로 묶어서 메인테이너한테 보냈는데 어찌될지는 모르겠습니다.

libmms의 외부 의존성은 소켓 라이브러리 밖에 없긴 한데, 윈도 포트를 고려를 안 해놔서 윈도의 경우 WinSock 함수를 쓰도록 패치를 했습니다. 윈도 프로그래밍 경험이 많지 않아서 역사적인 이유는 모르겠지만, WinSock이 유닉스 계열 소켓 함수와 거의 비슷하면서 조금씩 다른 부분들이 있어서 귀찮더군요.

처음에 WSAStartup을 안 부르고 테스트하다가 한참을 헤맸습니다. 더불어 snprintf나 strcasecmp, strncasemp도 윈도 쪽에 같은 이름으로 함수가 없어서 귀찮더군요. Glib이라도 쓰면 g_만 붙여서 g_snprintf, g_strcasecmp, g_strncasecmp로 사용하면 좋긴 한데, libmms 경우는 Glib 의존성을 제거한 흔적(glib.h)이 남아 있어서 그것도 안 되는 것 같고요.

새삼스러운 질문이지만 C에서 네트워크 관련 라이브러리를 리눅스 혹은 윈도로 포팅하는 가장 쉬운 방법은 무엇일까요?

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 언어를 지원하려고 했던 원래의 취지와는 잘 맞지 않게 된 것은 아닐까?

마이크로소프트웨어 1월호 원고

Posted 2006. 12. 22. 05:48
마감이 쫓기다가 겨우 마소 1월호 원고를 마감했습니다. 1월의 주제는 "포팅의 어려움"입니다.

우리가 일상적으로 사용하는 소프트웨어의 상당수는 윈도, 리눅스, 맥 OS X 등 다양한 플랫폼에서 동작하고 있다. 자바가상머신에 의해서 처음부터 멀티플랫폼(혹은 크로스 플랫폼이라고 불림)을 보장받는 자바 어플리케이션뿐만 아니라, 일반적인 C/C++ 프로그램도 여러 플랫폼을 지원하는 경우가 드물지 않게 되었다. 일례로, 대표적 웹브라우저인 파어어폭스(Firefox)는 윈도, 맥OS X, 리눅스 세 가지 버전을 동시에 배포하고 있다. 과거에는 멀티플랫폼을 지원하는데 드는 노력에 비해 추가적으로 얻을 수 있는 사용자 수가 적었기 때문에, 멀티플랫폼 지원은 막연한 환상에 그쳤다. 하지만 근래의 소프트웨어 기술의 발전 덕분에 멀티플랫폼 소프트웨어는 작은 비용으로 조금이라도 많은 사용자를 확보할 수 있는 수단이 되고 있고, 덕분에 많은 개발자들이 관심을 가지게 되었다. 이 글에서는 멀티플랫폼 소프트웨어 작성의 근간이 되는 포팅 레이어(porting layer)에 대해 살펴보자.

포팅 레이어의 예로

1) CDC JavaVM의 HPI(Host Programming Interface)
2) 아파치 웹서버의 APR(Apache Portable Runtime)
3) WIPI의 HAL(Hardware Abstraction Layer)

을 소개하고 있습니다.