운영체제 만들기는 노가다...

무조건적인 Open source는 아닙니다.
라이센스가 분명히 존재하고, 상용화하기 위해서는
fee를 지불해야 되는 것으로 알고 있습니다.

아울러 uCos 는 산업용제어쪽에서 많이 사용하고 있습니다.

source가 open되어있지만 상업적인 용도로 사용할 경우는
별도로 license fee가 있었던것같군요.

opensource project는 없을지 모르지만, 회사별로 자체적으로
개발해서 사용하고 있는 것으로 알고 있습니다.

문제는 RTOS를 어디까지의 범주로 볼것인가겠죠.
간단 scheduler수준의 nonMMU environment하에서 통신종단단말기
형태에 올릴 stack build-up이 가능한 수준은 많이들 만들어서
쓰고 있습니다.
VxWorks예를 드셨지만, 제법 오래전 자료에 대한 기억이라
좀 그렇긴 해도, 전미 RTOS market 점유율에서 Windriver가
차지하는 비율이 3%였습니다.(pSOS던가 Vertex사들이기 전이었던듯 하군요.)
그런데 황당했던건 house-made os가 50%를 넘었다는 겁니다.
즉 각자 상황에 특화해서 만들어썼단거죠.

국내에서도 MDS같은데서 만든것도 있고, 설대에서도 몇년전인가
그런걸 만들어내기도 했었습니다. 몇군데 더 있을테죠.

범주라는 측면에서 RTOS라고 하는 것이 좀 애매한 것은,
불필요한 기능이나 확장성/범용성을 추구함이 지나쳐
괜한 resource낭비가 이루어지기 십상이라는 점입니다.
아무래도 한정된 자원에서의 최적화가 목적이다보니...

LCD도 바로 붙일수 있고, 기본적인 stack도 올라있고, file system도
그럴싸하고... 붙이기 시작하면 한도 끝도 없지만,
진짜 RT라면 차라리 uCom programming이 낫습니다.
context switching을 위한 overhead도 없고, slice관리도 필요없습니다.
driver adaption layer가 줄어드니 그만큼 clock을 아낄수도 있습니다.

auto configure로 core+stack+api 뭐 이런식의 library 딱 나와주고,
할 일이라곤 bsp porting에 자체 application을 library위에 올려만
주면 되는 속편한 시스템도 좋긴 한데, 영 찝찝한건 덩치가
커지거나 내부를 알기 쉽지 않다는 점이 있습니다.
(상용일땐 더더욱)

두개를 절충한 시스템이 좋다고 봅니다.
그래서 time critical한 문제를 수행하는데는 scheduler를 꺼버리고,
단독 procedure로 동작시키고, normal operation시에만 사용하는
식으로 걍 만들어 쓰고 있습니다.

아이러니한건, 10여년전만해도 uCom programmer들끼리는
서로 "여긴 막장이야"라며 푸념하곤 했었는데, embedded라고 해서
그럴듯하게 포장되고부터는 다들 좋아라한다는 점 같습니다.

embedded쪽, 좀 과장된면이 있는것 같아 몇자 적어봤습니다.
실력을 봐도 uCom programming쪽 한 사람보다 unix계열 programmer가
더 좋더라구요^^;
아마도 software 기반이 확실한편이 더 발전할 여지가 많아서 그런듯 합니다.
아 오해는 마시구요. embedded쪽 사람이 그렇다는 일반화가 아닙니다.
제가 그렇다구요(기본기가 없단뜻^^;)

정말이지 리눅이에서 돌아가는 debugger만 있어줘도 냉큼 window
directory 지워버리겠습니다.
emacs에서 바로 연동되는 BDM이라. 어흑.ㅠ.ㅠ;
그런 몇가지 어플들이 국산화되면 참 좋겠는데...

Velos는 uC/OS나 eCOS처럼
라이브러리 형태의 커널로 알고 있는데요.
리눅스 커널을 기반으로 하고도 그런 형태가 가능한가요 ?

제가 알고 있는 os가 Velos인지는 확실하지 않은데,
서울대에서 몇년전에 만든 그 OS는 POSIX 표준에 따라
완전히 자체 개발한걸로 알고 있습니다.
cross platform이 linux였는지는 모르겠지만요...

좋은 말씀 감사합니다.

알려주신 키워드들에 대해 열심히 공부하고 싶습니다.

제가 얼마전부터 매우 작고 실용성은 별로 없는

실시간/임베디드용 커널을 만들려고 노력중인데요

먼저 제가 가지고 있는 하드웨어인 x86에서 시작해보려고 합니다만

키보드처리를 위한 인터럽트 처리에서 막힙니다.

이 문제만 해결하면 다른 인터럽트나 예외들의 처리에도

많이 도움이 될것 같은데요

APIC 초기화와 설정하고 x86 머신에서의 인터럽트 처리에 관해

INTEL 매뉴얼 외에 좀더 자세한 문서가 있으면

소개해주셨으면 좋겠습니다.

원리를 모르니 공개 운영체제들의 소스를 봐도 잘 이해가 안되서요.

제가 이제 곧 졸업인데 학교 공부를 소홀히 해서

말씀하신 기술들을 잘 이해를 못하고 있어서

기초가 많이 부족합니다.

그 외에도 좋은 문서가 있으면 소개해주셨으면 좋겠습니다.

혹시 uC/OS-II 포팅을 해보셨는지요 ?
Linux나 Windows 같은 형태의 커널과는 다릅니다.
라이브러리 형태의 운영체제라는 [용어]는 없겠지만
형태는 분명 라이브러리나 진배없죠.
커널과 유저 프로그램이 레이어로 나눠져있지 않거든요.
유저 프로그램[?]이 커널에 바로 링크되어 올라갑니다.
System Call 같은 것도 그냥 함수 호출이죠.

그리고 Shell 을 유저와 Loader 간의 통신을 담당하는 거라고
정의해버리기는 좀 애매한 감이 있습니다.
Shell 자체도 Load된 application이니까요.
Shell 스스로도 처리할 수 있는 것들이 많고요.

또 소위 자작운영체제도 사실 종류가 많겠죠.

꽤 오랫동안 운영체제를 만들려고 했던 제가 듣기에는 참...좀 그렇군요.
운영체제 만드는 게 그리 어려운 일이 아니면 만들기 어려운 프로그램이 어디 있겠습니까.
그리고 운영체제 수강했다고 운영체제 만들 수 있으면 운영체제가 여기 저기 널려 있을 껍니다.
운영체제는 그 어떤 프로그램보다 최악의 디버깅 환경 속에서 프로그램을 만드는 일입니다.
아무리 원격으로 디버깅하고 에뮬레이터를 써도 그냥 재부팅 되는 경우도 많고 에뮬레이터에도 버그가 존재하는 데 디버깅이 정말 만만한 일이 아닙니다.

대부분 운영체제 만들려고 하시는 분들이 "시장"에는 별로 관심이 없으시더군요.
저도 마찬가지구요.
돈 벌려고 만드는 것이 아니니까요.
돈 벌려고 운영체제 만드시려는 분들은 금방 그만 두시더군요.
운영체제 만들어서 돈 번다는 게 쉬운 일이 아니니까요.
그래서 대부분 x86에서 만드시는 겁니다.
그냥 자기 PC에 돌아가는 운영체제를 만들어야지 따로 하드웨어 사는 돈 안들어 가니까요.

제가 하고 싶은 말의 요지는 그분들이 좁은 시장에 눈독을 들이고 있는 게 아니라 겁니다.

운영체제 만드는 것이 노가다나 쉬운 일이라는 표현에 좀 흥분한 것 같군요.
저도 빨리 운영체제를 만들고 싶은 데 군인이라 제한사항이 많은 것이 참 안타깝습니다.

제가 평생의 숙원 사업으로 여기는

임베디드 커널 제작을 이렇게 쉽게 이야기하시는 분이

계시네요..

정말 세상은 넓고 사람은 많습니다.

dopesoul님 제 홈페이지에 한번 놀러오세요.

http//www.asmlove.co.kr 입니다.

dopesoul님 감사합니다.

비하하셨다는게 아니라 실력이 좋으시고

좋은 말씀을 해주셨다고 쓴거랍니다... oops

그쪽에 관련된 자료가 필요해지면 부탁드리겠습니다.

그렇지않아도 곧 모토로라 MPU로 프로젝트를 할것 같아서요..

여러분~~ 어셈러브 많이 놀러오세용~~~ lol

uP가 들어간 칩을 만들자마자 보드에 납땜해서 던져주고는 당장 어플리케이션을 돌리라고 위에서 지X하는데 정작 MDS 모니터는 멀뚱멀뚱 조용할 때....
할 수 없이 오실로스코프로 오실레이터부터 찍어봅니다.