OS를 공부하는데 있어서 OS가 동작하는 이론적인 문제도 중요하지만
실제로 OS가 어떻게 동작하는지 알아보는 일도 중요하다.
초보자 입장에서 현재 동작하고 있는 최신 리눅스 커널 소스를 보는 일은
이제 막 걸음마를 시작한 애가 장대 높이 뛰기 선수들이 쓰는 장대를 만지작
거리는 일과 다르지 않으리라 생각한다.
그래서 시작은 picoKernel과 linux 커널 0.1 버전을 분석해보는 일부터 시작하려 한다.
1. picoKernel
분석해보려는 picoKernel은 우리 교수님께서 만든 교육용 커널이다.
실제 소스의 길이도 2000정도 밖에 안되는 교수님 말을 빌리면 만만한 커널이다.
가벼워도 OS의 핵심적인 기능은 대부분 갖추고 있다.
물론 이것을 실제 운영체제로 사용하려면 각종 유틸들이나 파일시스템등 여러가지가
필요하지만 picoKernel 은 실제 OS 내부에서 사용하는 멀티태스킹, 스케줄링,
동기화에 필요한 뮤텍스, 세마포어, 공유메모리등이 구현되어 있다.
예전에 프로젝트 때문에 임베디드용 OS를 몇개 본적이 있었는데 그 구조가
picoKernel과 크게 다르지 않았다. 세부적인 내용은 조금씩 차이는 있지만
대략적인 구동방식이나 구조는 대동소이했다.
MicroC/OS나 ETRI에서 얼마전에 공개한 nanoQplus, 콜로라도 대학의 MANTIS 등과
같은 소형 임베디드 OS들은 모두 picoKernel과 같이 멀티태스킹과 동기화와 IPC를 위한
기능을 지원한다.
1.1 picoKernel 특징
picoKernel은 멀티태스킹이 가능한 OS이다. picoKernel자체가 하나의 프로세스이므로
프로세스내에서의 멀티태스킹은 thread방식이다.
picoKernel은 비선점형 스케줄링에 해당하는데 비선점형 자발적인 종료나 wait, 양보의 경우에만
다른 작업으로 제어권을 넘기게 되고 다른 인터럽트나 새로운 작업의 등록으로 인해
현재 작업중인 제어권이 바뀌지 않는 형태를 비선점형 스케줄링라고 한다.
picoKernel는 인터럽트의 처리를 제외하면 선점형 스케줄링으로 볼 수 도 있다.
picoKernel이 선점형 스케쥴링이 되려면 인터럽트에 대한 처리를 따로 처리해야하며
이때 발생하는 크리티컬 섹션 문제가 해결되어야만 선점형 스케쥴링이 될 수 있다.
여담..
프로젝트 할 때 AVR에 타이머 인터럽트를 통해서 선점형 스케쥴러 비스므리하게
강제적으로 시간이 지나면 스케줄링이 일어나게 했던 적이 있었는데.
OS와 통신모듈을 통합하고 나니까 통신모듈이 동작을 안하는 것이다.
통신모듈에 문제가 있는 줄 알고 몇주를 헤맸는데 결국 문제는 타이머 인터럽트로 인한
강제적인 스케줄링으로 인해 통신중에 문맥이 바뀌어버리는 것이다.
당연히 데이터가 날라가는 중에 스케줄링이 일어나면 데이터가 전송되다 만다..
타이머 인터럽트는 생각도 안하던 문제여서 통신 모듈상에 인터럽트 방지도 안해놨고
문맥교환시 데이터의 동기화역시 생각도 안하던 문제여서 결국 타이머 인터럽트에
걸려있던 강제 스케줄링을 삭제했던 기억이 있다.
1.2 picoKernel의 동작
picoKernel은 실제 OS라기보다는 교육목적으로 만들어졌기 때문에 리눅스나
Cygwin같은 환경에서 하나의 프로세스로 동작한다. 커널 하나가 하나의 프로세스로 동작하고
그 안에서 여러 thread를 생성해서 동작한다.
picoKernel은 기본적으로 nullMain과 userMain 2개의 thread로 동작한다.
nullMain은 말 그대로 비어있는 루틴이고 userMain은 사용자가 일을 처리할 때
사용하는 루틴이다. 두개의 thread가 등록이 되고 우선순위에 따라 동작한다.
thread생성시 userMain의 우선순위가 높기 때문에 userMain함수안에서
다른 thread를 생성하지 않는다면 userMain을 먼저 처리하고 끝나면
nullMain을 실행하고 종료한다.
nullMain을 보면 thread가 실행되면 바로 threadYield로 다른 thread로 제어권을 넘긴다.
userMain에서 thread를 생성하면 그 우선순위에 따라 thread를 실행하고
종료하게 된다.
실제로 OS가 어떻게 동작하는지 알아보는 일도 중요하다.
초보자 입장에서 현재 동작하고 있는 최신 리눅스 커널 소스를 보는 일은
이제 막 걸음마를 시작한 애가 장대 높이 뛰기 선수들이 쓰는 장대를 만지작
거리는 일과 다르지 않으리라 생각한다.
그래서 시작은 picoKernel과 linux 커널 0.1 버전을 분석해보는 일부터 시작하려 한다.
1. picoKernel
분석해보려는 picoKernel은 우리 교수님께서 만든 교육용 커널이다.
실제 소스의 길이도 2000정도 밖에 안되는 교수님 말을 빌리면 만만한 커널이다.
가벼워도 OS의 핵심적인 기능은 대부분 갖추고 있다.
물론 이것을 실제 운영체제로 사용하려면 각종 유틸들이나 파일시스템등 여러가지가
필요하지만 picoKernel 은 실제 OS 내부에서 사용하는 멀티태스킹, 스케줄링,
동기화에 필요한 뮤텍스, 세마포어, 공유메모리등이 구현되어 있다.
예전에 프로젝트 때문에 임베디드용 OS를 몇개 본적이 있었는데 그 구조가
picoKernel과 크게 다르지 않았다. 세부적인 내용은 조금씩 차이는 있지만
대략적인 구동방식이나 구조는 대동소이했다.
MicroC/OS나 ETRI에서 얼마전에 공개한 nanoQplus, 콜로라도 대학의 MANTIS 등과
같은 소형 임베디드 OS들은 모두 picoKernel과 같이 멀티태스킹과 동기화와 IPC를 위한
기능을 지원한다.
1.1 picoKernel 특징
picoKernel은 멀티태스킹이 가능한 OS이다. picoKernel자체가 하나의 프로세스이므로
프로세스내에서의 멀티태스킹은 thread방식이다.
picoKernel은 비선점형 스케줄링에 해당하는데 비선점형 자발적인 종료나 wait, 양보의 경우에만
다른 작업으로 제어권을 넘기게 되고 다른 인터럽트나 새로운 작업의 등록으로 인해
현재 작업중인 제어권이 바뀌지 않는 형태를 비선점형 스케줄링라고 한다.
picoKernel는 인터럽트의 처리를 제외하면 선점형 스케줄링으로 볼 수 도 있다.
picoKernel이 선점형 스케쥴링이 되려면 인터럽트에 대한 처리를 따로 처리해야하며
이때 발생하는 크리티컬 섹션 문제가 해결되어야만 선점형 스케쥴링이 될 수 있다.
여담..
프로젝트 할 때 AVR에 타이머 인터럽트를 통해서 선점형 스케쥴러 비스므리하게
강제적으로 시간이 지나면 스케줄링이 일어나게 했던 적이 있었는데.
OS와 통신모듈을 통합하고 나니까 통신모듈이 동작을 안하는 것이다.
통신모듈에 문제가 있는 줄 알고 몇주를 헤맸는데 결국 문제는 타이머 인터럽트로 인한
강제적인 스케줄링으로 인해 통신중에 문맥이 바뀌어버리는 것이다.
당연히 데이터가 날라가는 중에 스케줄링이 일어나면 데이터가 전송되다 만다..
타이머 인터럽트는 생각도 안하던 문제여서 통신 모듈상에 인터럽트 방지도 안해놨고
문맥교환시 데이터의 동기화역시 생각도 안하던 문제여서 결국 타이머 인터럽트에
걸려있던 강제 스케줄링을 삭제했던 기억이 있다.
1.2 picoKernel의 동작
picoKernel은 실제 OS라기보다는 교육목적으로 만들어졌기 때문에 리눅스나
Cygwin같은 환경에서 하나의 프로세스로 동작한다. 커널 하나가 하나의 프로세스로 동작하고
그 안에서 여러 thread를 생성해서 동작한다.
picoKernel은 기본적으로 nullMain과 userMain 2개의 thread로 동작한다.
nullMain은 말 그대로 비어있는 루틴이고 userMain은 사용자가 일을 처리할 때
사용하는 루틴이다. 두개의 thread가 등록이 되고 우선순위에 따라 동작한다.
thread생성시 userMain의 우선순위가 높기 때문에 userMain함수안에서
다른 thread를 생성하지 않는다면 userMain을 먼저 처리하고 끝나면
nullMain을 실행하고 종료한다.
nullMain을 보면 thread가 실행되면 바로 threadYield로 다른 thread로 제어권을 넘긴다.
userMain에서 thread를 생성하면 그 우선순위에 따라 thread를 실행하고
종료하게 된다.
