제가 생각할때, 하하님께서 그런것들이 왜 필요한지 한번쯤 생각해 보시면 이해가 가리라 생각합니다.
우리가 흔히 말하는 커널은 여러가지 형태로 존재할 수 있습니다.
커널은 사용자 프로그램 하드웨어 자원간의 공통적인 접근을 위한 교량역할을 하는데, 임베디드 환경에서는 이러한 커널이 단순히 라이브러리와 인터럽트 핸들러로만 존재할 수 있어서 사용자 프로그램과 함께 링킹해서 하나의 바이너리로 만들 수 있는가 하면(같은 주소영역), 리눅스와 다른 일반적인 운영체제처럼, 별도의 이미지 바이너리로 존재할 수도 있죠(서로 다른 논리주소영역).
즉, 사용자 프로그램은 어떤 작업을 위해선 꼭 한번 이상은 커널에게 몬가를 시킵니다. 자신이 할 수 없는 일을요... ; 형태에 따라서 단순히 커널 함수를 호출하거나, 커널 콜(시스템 콜, 트랩)을 하게 되죠.
단순하게 생각한다면, 커널함수가 호출되거나(커널콜을 지원하지 않는 RTOS환경, 드라이버는 제외) 커널 콜이 유입되면 그때부턴 커널모드라고 생각할 수도 있죠(여기에 대해서 다른 분들이 반론을 제기할지도 모르겠네요..ㅎㅎ^^)
사용자 프로그램 입장에서는 커널 내의 작업 진행에 대해서는 아무것도 모릅니다. 단지, 주어진 API 형태로만 정보를 주고 받는거죠. 하지만, 내부 작업을 위해서는 커널의 다양한 자원을 제어하게 되는데, 이러한 자원들은 당연히 사용자 프로그램과는 차단되어야 할 필요가 있는거죠. 커널의 역할 중에 가장 중요한 기능 중에 하나가 바로 자원관리이니까요.
그럼, 커널모드와 사용자모드가 개념적인 의미일 뿐이지 않느냐는 생각하실지도 모르겠죠.. 하지만, 그건 절대 아닙니다.
사용자 프로그램으로부터의 침범이 보장되는 게 커널모드입니다. supervisor mode라고도 하는데, 이는 CPU에서 제공하거나, 아주 특수한 환경같은 경우에는 다른 방법을 사용하기도 합니다.
일반적인 경우에는, 일단, 사용자 프로그램이 사용자모드에서 커널모드로 진입하기 위해서는 원하는 서비스 번호를 레지스터에 써두고, trap exception을 유발시켜, 시스템 콜을 시도합니다.
CPU에서 받아들일 수 있는 비동기 인터럽트의 하나의 trap이 발생하면, 미리 준비된 trap핸들러가 수행하게 되는데, 사실상 여기서 부터는 모든 제어권이 커널이라고 봐야겠죠. 트랩핸들러는 현재 수행중이었던 타스크나 프로세서를 현재 시스템 콜을 처리하기 위해서 suspend시키고 작업을 진행한후, 필요하다면 suspend되었던 타스크나 프로세서를 깨우게 됩니다.(설명이 장황할거 같아서, context-switching에 관한부분은 생략합니다)
아시겠지만, 이런 트랩이 없다면, 논리적인 메모리 영역이 엄연히 다른 사용자 프로그램과 커널간의 통신이 원활하지 않을 겁니다.
이런 트랩을 제공하지 않는 운영체제에서는 단순히 커널 함수를 호출할 수도 있는데 대개는 해당 커널 함수 앞부분에는 CPU에서 제공하는 모드 레지스터를 supervisor모드로 설정하고 진행하게 됩니다. 동일 메모리 공간에 존재하는 커널과 사용자 프로그램간의 충돌을 막기 위해서 supervisor 모드가 접근하는 영역을 보호받기 위한것이죠. 나머지 절차는 거의 동일하죠.
제가 생각할때, 커널모드와 사용자모드의 가장 큰 차이점은 물리적인 장치 접근 허용여부라고 생각합니다. 물론 커널모드내에서도 2-3가지의 다른 권한이 들어가긴 하지만, 이런 부분들은 디바이스별로 별도로 존재하는 경우가 대다수이죠. 커널을 어떤 시스템에 이식할 경우, 대부분의 시스템 엔지니어들이 고민하는게(?) 물리장치들에 대한 메모리 맵과 Cache Inhibit영역 Cache방식 등과 접근 위치/권한 등에 대한 부분들입니다. 서로 이런 부분들이 커널모드내에서 관리해야 할 정보들이기 때문이죠. 시스템의 성능과 안정성에 아주 밀접한 관계죠.
만일 커널모드가 없다면?...ㅎㅎ 사실 없어도 되겠죠... 임베디드 환경에서 개발하는 하나의 이미지 형태의 어플리케이션에서는 사용자 프로그램 조차도 장치제어에 대한 관리기능을 다 포함하게 되는거죠...상당히 머리가 아프죠.
굳이 비유를 하자면, 무인식당에 가서, 내가 혼자서 재료넣고 음식을 만들어서 먹는다고 상상해 보세요. 혼자 먹을때야 괜찮겠죠. 여러사람이 동시에 와서 음식을 만들고 먹는다면, ㅎㅎ... 대충 상상이 가실거에요. 재료도 비효율적으로 낭비되고, 식당이 엉망이 되겠죠.
님이 만일 기회가 된다면, 임베디스 시스템의 모니터 프로그램을 한번 개발해 보신다면, 커널모드를 이해할 수 있는 좋은 기회가 될지도 모르겠네요. OS커널보다는 복잡하진 않지만, 장치관리에 대한 기초적인 경험을 쌓을 수 있거든요.
응용 프로그램을 개발하는 경우라면, 사실 시스템 콜이니 커널 콜이니 하는 부분에 대해서 거의 모르고(사실은 서버 프로그램과 같이 성능을 고려한 시스템 개발시에는 필요) 사용합니다.
커널 서비스는 사용자 프로그램과 하드웨어간의 교량역할이긴 하지만, 여전히 응용프로그램 입장에서 본다면, 그 커널 인터페이스 자체만으로는 복잡해 보이고 사용하기 힘들어 보이는게 사실입니다. 임베디드 환경에서는(제가 이쪽에 일을 해서 그런지 자꾸 언급하네요..ㅎㅎ) 사실 친숙한 환경이긴 하지만요.
따라서, 이런 부분들로부터 사용자 프로그램 입장에서 효율적이고 편리하게 사용할 수 있도록 여러가지 라이브러리 형태로(한 꺼풀 씌운거죠) 제공하여 사용할 수도 있습니다. 물론, 저수준으로도 직접적으로 커널콜을 사용할 수도 있고요.
우리가 흔히 아무생각없이 사용하는 printf()함수를 생각해 보세요.
스택에 주어진 출력포맷과 인자값들의 값,타입 등에 참조하여 하나의 문자열로 만들어서, 최종적으로 현재 활성화된 터미널로 출력하는 과정을 상상해 보세요.
최종적으로 문자열을 터미널로 출력하기 이전까지의 작업은 응용 프로그램의 사용자 모드에서 이루어지게 되는것이지요. 마지막으로 출력될 문자열에 대한 정보를 스택에 두고, 서비스 번호를 레지스터에 입력한 후 시스템 콜 exception을 유발시키는 거죠. 여기서 부턴 커널 모드가 되는겁니다.
우리가 흔히 사용하고 있는 함수들을 보면 커널콜을 몇번 씌워서 사용하고 있기 때문에 그 자체가 커널콜인걸로 착각하시는 분들도 있을지도 모르겠네요. 이런 라이브러리 자체는 모두 사용자모드에서 동작하고, 최종적으로 커널콜을 수행하고 그 결과를 반환해 주는거죠.
그리고 실제로 커널콜은 그다지 많은 양의 연산을 수행하는 일들이 아닙니다. 대부분의 가공연산 작업들은 사용자 수준에 의해서 주어집니다. 왜 그런지는 생각해 보시면 알겁니다.
어떤 주제로 공부하고 계신지는 잘 모르겠지만, POSIX에 대한 내용도 참조해 보심 어떨까요?
잘 와닿지 않는다는 예로 전...시스템 콜을 하면 사용자 모드에서
잘 와닿지 않는다는 예로 전...
시스템 콜을 하면 사용자 모드에서 커널 모드로
진입한다. 이말도 정말 저한텐 너무 추상적이라
그냥 그렇다..라고 관념적? 으로 알고 있습니다.
이해가 아닌.... ㅋ
“바람에게도 길은 있다. 나는 비로소 나의 길을 가느니. 길은 언제나 어디에나 있다.”
[quote="하하"]잘 와닿지 않는다는 예로 전...시스템 콜을
한마디로 쉽게 설명할 수 있을 만한 주제가 아닌 것 같군요.
Operating System Concept (일명 공룡책) 을 추천합니다.
즐겁게 살아 볼까나~*
지금 보고 있습니다 ㅋ보면서 공유할 수 있는 무엇인가가 있지 않을
지금 보고 있습니다 ㅋ
보면서 공유할 수 있는 무엇인가가 있지 않을까
해서요..
ㅋ
솔직히 책을 보면서도 잘 이해가 안되서.. 이런.
조각들을. 좀 이해 하면 책을 읽는데도 도움이 되지
않을까 합니다 ㅋ
“바람에게도 길은 있다. 나는 비로소 나의 길을 가느니. 길은 언제나 어디에나 있다.”
제가 생각할때, 하하님께서 그런것들이 왜 필요한지 한번쯤 생각해 보시면
제가 생각할때, 하하님께서 그런것들이 왜 필요한지 한번쯤 생각해 보시면 이해가 가리라 생각합니다.
우리가 흔히 말하는 커널은 여러가지 형태로 존재할 수 있습니다.
커널은 사용자 프로그램 하드웨어 자원간의 공통적인 접근을 위한 교량역할을 하는데, 임베디드 환경에서는 이러한 커널이 단순히 라이브러리와 인터럽트 핸들러로만 존재할 수 있어서 사용자 프로그램과 함께 링킹해서 하나의 바이너리로 만들 수 있는가 하면(같은 주소영역), 리눅스와 다른 일반적인 운영체제처럼, 별도의 이미지 바이너리로 존재할 수도 있죠(서로 다른 논리주소영역).
즉, 사용자 프로그램은 어떤 작업을 위해선 꼭 한번 이상은 커널에게 몬가를 시킵니다. 자신이 할 수 없는 일을요... ; 형태에 따라서 단순히 커널 함수를 호출하거나, 커널 콜(시스템 콜, 트랩)을 하게 되죠.
단순하게 생각한다면, 커널함수가 호출되거나(커널콜을 지원하지 않는 RTOS환경, 드라이버는 제외) 커널 콜이 유입되면 그때부턴 커널모드라고 생각할 수도 있죠(여기에 대해서 다른 분들이 반론을 제기할지도 모르겠네요..ㅎㅎ^^)
사용자 프로그램 입장에서는 커널 내의 작업 진행에 대해서는 아무것도 모릅니다. 단지, 주어진 API 형태로만 정보를 주고 받는거죠. 하지만, 내부 작업을 위해서는 커널의 다양한 자원을 제어하게 되는데, 이러한 자원들은 당연히 사용자 프로그램과는 차단되어야 할 필요가 있는거죠. 커널의 역할 중에 가장 중요한 기능 중에 하나가 바로 자원관리이니까요.
그럼, 커널모드와 사용자모드가 개념적인 의미일 뿐이지 않느냐는 생각하실지도 모르겠죠.. 하지만, 그건 절대 아닙니다.
사용자 프로그램으로부터의 침범이 보장되는 게 커널모드입니다. supervisor mode라고도 하는데, 이는 CPU에서 제공하거나, 아주 특수한 환경같은 경우에는 다른 방법을 사용하기도 합니다.
일반적인 경우에는, 일단, 사용자 프로그램이 사용자모드에서 커널모드로 진입하기 위해서는 원하는 서비스 번호를 레지스터에 써두고, trap exception을 유발시켜, 시스템 콜을 시도합니다.
CPU에서 받아들일 수 있는 비동기 인터럽트의 하나의 trap이 발생하면, 미리 준비된 trap핸들러가 수행하게 되는데, 사실상 여기서 부터는 모든 제어권이 커널이라고 봐야겠죠. 트랩핸들러는 현재 수행중이었던 타스크나 프로세서를 현재 시스템 콜을 처리하기 위해서 suspend시키고 작업을 진행한후, 필요하다면 suspend되었던 타스크나 프로세서를 깨우게 됩니다.(설명이 장황할거 같아서, context-switching에 관한부분은 생략합니다)
아시겠지만, 이런 트랩이 없다면, 논리적인 메모리 영역이 엄연히 다른 사용자 프로그램과 커널간의 통신이 원활하지 않을 겁니다.
이런 트랩을 제공하지 않는 운영체제에서는 단순히 커널 함수를 호출할 수도 있는데 대개는 해당 커널 함수 앞부분에는 CPU에서 제공하는 모드 레지스터를 supervisor모드로 설정하고 진행하게 됩니다. 동일 메모리 공간에 존재하는 커널과 사용자 프로그램간의 충돌을 막기 위해서 supervisor 모드가 접근하는 영역을 보호받기 위한것이죠. 나머지 절차는 거의 동일하죠.
제가 생각할때, 커널모드와 사용자모드의 가장 큰 차이점은 물리적인 장치 접근 허용여부라고 생각합니다. 물론 커널모드내에서도 2-3가지의 다른 권한이 들어가긴 하지만, 이런 부분들은 디바이스별로 별도로 존재하는 경우가 대다수이죠. 커널을 어떤 시스템에 이식할 경우, 대부분의 시스템 엔지니어들이 고민하는게(?) 물리장치들에 대한 메모리 맵과 Cache Inhibit영역 Cache방식 등과 접근 위치/권한 등에 대한 부분들입니다. 서로 이런 부분들이 커널모드내에서 관리해야 할 정보들이기 때문이죠. 시스템의 성능과 안정성에 아주 밀접한 관계죠.
만일 커널모드가 없다면?...ㅎㅎ 사실 없어도 되겠죠... 임베디드 환경에서 개발하는 하나의 이미지 형태의 어플리케이션에서는 사용자 프로그램 조차도 장치제어에 대한 관리기능을 다 포함하게 되는거죠...상당히 머리가 아프죠.
굳이 비유를 하자면, 무인식당에 가서, 내가 혼자서 재료넣고 음식을 만들어서 먹는다고 상상해 보세요. 혼자 먹을때야 괜찮겠죠. 여러사람이 동시에 와서 음식을 만들고 먹는다면, ㅎㅎ... 대충 상상이 가실거에요. 재료도 비효율적으로 낭비되고, 식당이 엉망이 되겠죠.
님이 만일 기회가 된다면, 임베디스 시스템의 모니터 프로그램을 한번 개발해 보신다면, 커널모드를 이해할 수 있는 좋은 기회가 될지도 모르겠네요. OS커널보다는 복잡하진 않지만, 장치관리에 대한 기초적인 경험을 쌓을 수 있거든요.
yeppiguy 님 너무 감사드립니다. 속 시원해졌습니다
yeppiguy 님
너무 감사드립니다.
속 시원해졌습니다 .
발판 삼아 책 읽는데 가속이 붙을 거 같습니다.
다시 한번 감사드립니다. ^^;
참고로 싱글 유저 기반인 예전 DOS에선.. 커널 모드 사용자 모드가
필요 없을 듯도 합니다. ㅋ
쓰고 보니 이 기회에 답변 주시는 분들께도 모두 모두 감사 드립니다. ㅎㅎ
“바람에게도 길은 있다. 나는 비로소 나의 길을 가느니. 길은 언제나 어디에나 있다.”
그런데 한가지 의문이 듭니다.프로세스가 사용자 모드와 커널 모드를
그런데 한가지 의문이 듭니다.
프로세스가 사용자 모드와 커널 모드를 왔다 갔다
하며 실행이 되는데
커널 모드가 하는 일들은 쉽게 떠올르지만 예를들어
IO 작업.. 사용자 모드에서만 할 수 있는 일은 무엇이
있을까요?
“바람에게도 길은 있다. 나는 비로소 나의 길을 가느니. 길은 언제나 어디에나 있다.”
사용자 모드 지역 변수 처리 함수 호출 수행
사용자 모드
지역 변수 처리
함수 호출 수행 후 리턴 주소 저장
함수 호출에 필요한 인자들 관리(?)
ㅎㅎ
“바람에게도 길은 있다. 나는 비로소 나의 길을 가느니. 길은 언제나 어디에나 있다.”
참고링크입니다http://bbs.kldp.org/viewtopic.p
참고링크입니다
http://bbs.kldp.org/viewtopic.php?t=349
어디까지나참고．．．
세포분열중......
응용 프로그램을 개발하는 경우라면, 사실 시스템 콜이니 커널 콜이니 하는
응용 프로그램을 개발하는 경우라면, 사실 시스템 콜이니 커널 콜이니 하는 부분에 대해서 거의 모르고(사실은 서버 프로그램과 같이 성능을 고려한 시스템 개발시에는 필요) 사용합니다.
커널 서비스는 사용자 프로그램과 하드웨어간의 교량역할이긴 하지만, 여전히 응용프로그램 입장에서 본다면, 그 커널 인터페이스 자체만으로는 복잡해 보이고 사용하기 힘들어 보이는게 사실입니다. 임베디드 환경에서는(제가 이쪽에 일을 해서 그런지 자꾸 언급하네요..ㅎㅎ) 사실 친숙한 환경이긴 하지만요.
따라서, 이런 부분들로부터 사용자 프로그램 입장에서 효율적이고 편리하게 사용할 수 있도록 여러가지 라이브러리 형태로(한 꺼풀 씌운거죠) 제공하여 사용할 수도 있습니다. 물론, 저수준으로도 직접적으로 커널콜을 사용할 수도 있고요.
우리가 흔히 아무생각없이 사용하는 printf()함수를 생각해 보세요.
스택에 주어진 출력포맷과 인자값들의 값,타입 등에 참조하여 하나의 문자열로 만들어서, 최종적으로 현재 활성화된 터미널로 출력하는 과정을 상상해 보세요.
최종적으로 문자열을 터미널로 출력하기 이전까지의 작업은 응용 프로그램의 사용자 모드에서 이루어지게 되는것이지요. 마지막으로 출력될 문자열에 대한 정보를 스택에 두고, 서비스 번호를 레지스터에 입력한 후 시스템 콜 exception을 유발시키는 거죠. 여기서 부턴 커널 모드가 되는겁니다.
우리가 흔히 사용하고 있는 함수들을 보면 커널콜을 몇번 씌워서 사용하고 있기 때문에 그 자체가 커널콜인걸로 착각하시는 분들도 있을지도 모르겠네요. 이런 라이브러리 자체는 모두 사용자모드에서 동작하고, 최종적으로 커널콜을 수행하고 그 결과를 반환해 주는거죠.
그리고 실제로 커널콜은 그다지 많은 양의 연산을 수행하는 일들이 아닙니다. 대부분의 가공연산 작업들은 사용자 수준에 의해서 주어집니다. 왜 그런지는 생각해 보시면 알겁니다.
어떤 주제로 공부하고 계신지는 잘 모르겠지만, POSIX에 대한 내용도 참조해 보심 어떨까요?
strace를 통해 내가 만든 프로그램을 돌리면 ..어떻게 sys
strace를 통해 내가 만든 프로그램을 돌리면 ..
어떻게 system call을 호출 진행 하는지 볼수 있습니다
이 방법 이해 하는데 좋은거 같아서.. ㅎㅎ
“바람에게도 길은 있다. 나는 비로소 나의 길을 가느니. 길은 언제나 어디에나 있다.”
댓글 달기