100 likes | 294 Views
결론 : 공짜 점심은 없다 !. 2003 년 11 월 박재호 ( jrogue@netian.com ). 임베디드 리눅스의 한계 (1). 리눅스는 특효약인가 ? 아니다 . 이미 언급한 바와 같이 어떤 기술도 특효약일 수 없다 . 임베디드 시스템에 리눅스를 채택하기 어려운 이유 거대한 커널 크기 CPU 성능이 떨어지고 메모리 크기에 제약이 심한 장치에는 이식할 수 없다. 임베디드 리눅스의 한계 (2). 임베디드 시스템에 리눅스를 채택하기 어려운 이유 ( 계속됨 ) 공개 라이센스 문제
E N D
결론: 공짜 점심은 없다! 2003년 11월 박재호(jrogue@netian.com)
임베디드 리눅스의 한계(1) • 리눅스는 특효약인가? • 아니다. • 이미 언급한 바와 같이 어떤 기술도 특효약일 수 없다. • 임베디드 시스템에 리눅스를 채택하기 어려운 이유 • 거대한 커널 크기 • CPU 성능이 떨어지고 메모리 크기에 제약이 심한 장치에는 이식할 수 없다.
임베디드 리눅스의 한계(2) • 임베디드 시스템에 리눅스를 채택하기 어려운 이유(계속됨) • 공개 라이센스 문제 • 개발한 소프트웨어를 외부로 공개하기 어려울 경우에 라이센스 문제가 걸릴 수 있다. • 보안과 안정성 문제 • 상용 서비스를 받지 않는 이상 다른 사람에게 책임을 묻기 어렵다. • 적합성과 시장 압력 • 시스템 종류에 따라 적합하지 않을 수 있다. 예) 단순 타이머 • 기존 윈도우 운영체제에 익숙한 소비자나 투자가가 리눅스를 외면할 수도 있다.
임베디드 리눅스의 한계(3) • 임베디드 리눅스의 한계 • 실시간성: 임베디드 시스템을 위한 전용 OS에 비해 취약하다. 최근에는 다음과 같은 방식으로 리눅스에 실시간성을 보강하는 추세이다. • 최근 몬타비스타에서 선점형(preemptible) 커널 발표 • 실시간을 지원하도록 스케쥴러를 개선하려는 움직임 • 부 커널 방식(RTLinux와 RTAI) 커널 모듈 개발 • 메모리와 전력: 여전히 전용 OS와 비교하여 부족한 점이 많다. • 윈도우 시스템: 덩치가 크거나 안정화 작업이 필요하다.
임베디드와 리눅스의 숙명적 만남(1) • 임베디드 리눅스와 개발 생산성 • 하드웨어가 나오기 전에 다른 플랫폼에서 테스트할 수 있다. • vmware와 같은 가상 기계를 사용해서, 매번 컴퓨터를 재시동하지 않고서도 필요한 테스트가 가능하다. • 현존하는 최강의 다중 플랫폼 지원 개발환경인 gcc, gdb를 사용할 수 있다. • 개발 환경과 동작 테스트 환경을 모두 리눅스로 표준화할 수 있으며, 개발 지원 툴을 사용해서 개인이 아니라 그룹 차원에서 소프트웨어 개발을 진행할 수 있다. • 오픈 소스 모델로 인한 풍부한 정보 공개를 활용한다.
임베디드와 리눅스의 숙명적 만남(2) • 임베디드 리눅스의 전략적 가치 • 공개 소스 소프트웨어: 로열티 문제 해결 • 두터운 개발자 층: 수 많은 리눅스 프로그래머 • 검증된 운영 시스템: 10년에 걸쳐 사용 • 다양한 환경 지원: x86, alpha, ppc, SA, sparc, 메인 프레임에 이르기까지 각종 CPU 지원 • 모듈화, 이식성: 쉽고 빠르게 불필요한 부분을 빼고 필요한 부분을 추가 • 개발 과정 단순화: PC에서 개발 대상 플랫폼으로 이식
전략적인 고려 사항(1) • 목표를 염두에 둔 제품 특성 파악<판단기준> • 리눅스나 윈도우CE와 같은 운영체제가 필요한가? • 반드시 리눅스를 써야하나? • (리눅스) 성능과 기능면에서 부족한 점은 없나? • (리눅스) 하드웨어 설계와 구현에 문제는 없나? • (리눅스) 기존 제품으로 이식하는 데 문제는 없나? • (리눅스) 소비자 반응은 어떠한가? 제품 판매에 불리하지는 않나?
전략적인 고려 사항(2) • 개발에 필요한 인적 자원 확보<판단 기준> • 소프트웨어 인력 중심이냐 하드웨어 인력 중심이냐? • 각 부문에 얼마나 숙련된 인력을 투입할 것인가? • 하드웨어 인력이 프로젝트를 이끌 것인가, 소프트웨어 인력이 프로젝트를 이끌 것인가? • 응용 프로그램 이외에 이식과 장치 드라이버 개발자를 별도로 둘 것인가?
전략적인 고려 사항(3) • 기술 도입<판단 기준> • 참조 타겟 보드를 도입할 것인가, 직접 만들 것인가? • 상용 배포판과 기술 서비스를 도입할 것인가, 일반 배포판과 인터넷으로 해결한 것인가? • 하드웨어와 소프트웨어 개발자를 어떻게 교육시킬 것인가? 학원, 강사초빙? • 장치 드라이버 기술 지원 서비스를 도입할 것인가? • 응용 프로그램을 위한 상용 라이브러리와 컴포넌트를 도입할 것인가? • 완성품 형식의 상용 응용 프로그램을 도입할 것인가?
전략적인 고려 사항(4) • 하드웨어와 소프트웨어 제약<판단 기준> • 가격으로 인해 하드웨어나 소프트웨어 규격에 가해지는 제약은 없는가? • 전원, 발열, 크기 문제, 안정성, 가용성, 보안 유지를 위해 필요한 컴포넌트는 없는가? • 하드나 소프트 실시간이 필요하지 않은가? • 호환성이나 표준 준수에 문제는 없는가? 네트워크 프로토콜을 맞춰야 하나?